Dear all,

please find below the minute of today's TSC. I am also reattaching the PDF with Frank's presentation about ADAC for your convenience.

Thanks,

Antonio

Attendees:

Franck Albesa (STM)

Antonio (Arm)

Frank K (Nordic)

Maulik (Arm)

Kangkang (Futurewei)

Dominik Ermel (Nordic)

Julius Werner (Google)

Dan Handley (Arm)

Ruchika (NXP)

Camille (ProvenRun)

David Brown (Linaro)

Presentation about ADAC

* History and architecture of the ADAC system components

* Mailbox communication for host/device

ADAC as a first class citizen in TF-M

-> ADAC as part of the platform RoT as first class citizen (bringing them above platform scope/vendor scope)

-> Ideally do not treat them as an addition

-> Where to place it? BootROM, Flash bootloader, runtime FW. At the time it was decided to put it close to the bootloader, i.e. early after boot or activated after a reset behaviour

Crypto must be ported to PSA Crypto to be consistent with the overall story

* Usage of platform keys: That item still needs broader standardization

* Support for more complex topologies (i.e. Hybrid platforms, i.e. support for RSE enabled platforms)

* RSE enabled-like architectures we believe will be common in the years to come

* Increase the visibility of the documentation when ADAC becomes a standard feature, i.e. improved guides

Proposal: ADAC task force (Share responsibilities between individuals in the TF.org community across different companies as Arm has limited bandwidth to entirely own it)

Organize how to handle the collaboration, how to track work, i.e. design tasks and track them, regular meetings between involved parties

Keep the collaboration general instead of trying to steer towards company specific features/requirements

Design stage around emails (maybe complex to follow), but at the beginning better to have meetings first

Full time effort or more spread out? should we target LTS or more long term development on dev branch? needs to be balanced between commitments and stability of LTS branches

Platform keys: need to be tidied up (likely standardized int he context of Mbed TLS as Tf-M currently supports

them through out-of-tree patches. This item bridges with opaque driver concept. ADAC needs to be able to fully

use platform keys in context of PSA Crypto / drivers usage: this is a fundamental security requirement (handle keys correctly and fulfilling isolationr requirements)

* reserved key IDs for ADAC? to be investigated

Forwarding APIs: Call into a different entity rather than the secure images, but ownership remains centralized

-> example: access keys, or certificates, or lifecycle states, held in different compoents external to the TF-M FW image

-> intermediary which owns the computation but forwards the information to other parties/peripherals/components/scopes that actually implement the computation

HAL abstraction: Improved and established HAL interface will improve code reusability, it will improve visibility in the overall project

Closing rationale: Enable TF-M's feature set to fufill market requirements for all partners

Questions:

Maulik (Arm maintainer for ADAC): I worked on some improved docs in the last couple weeks. Questions about forwarding API: is it some message passing between TFM runtime and bootloader, or TFM and external components? Data oriented approach, the design to be finalized as part of the task force design focus.

ADAC is designed by HW designers need to make it friendly for SW

Franck (STM): Integration with TFM: Better to keep ADAC as indepedent of TFM (i.e. integrate it with other places), i.e. connected to where to place ADAC functionalities discussions. There is convenience in doing high level APIs (i.e. simplicity), but it might isolate the implementation too much. More code sharing is beneficial in that context. Forwarded API question: Is it the concept to be able to reuse the ADAC component in different places, or is it like a service where I can share in other layers? Frank: JTAG access based for many companies, our aim is to have PSA ADAC as a service, forwarding allows to have

implementations where it has to be, the ownership is centralized but the computation is deferred to some other components. Central concept different from callback: it is data sharing / forwarding.