Hi all
Let me know if you have any topics for tomorrow's TSC.
After a few months break, we plan to restart the project roadmap updates. The next one on the list is OP-TEE but I'm guessing it's too late notice for anyone from Linaro to be available got this (e.g. Ilias)? The following one on the list is TF-M so the current agenda is:
* TF-M roadmap update (Shebu)
* fTPM enablement plans in Arm/Linaro (Dan/Shebu)
Regards
Dan.
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.
Dear all,
the meeting agenda for tomorrow's TSC is as below:
*
Discussion about ADAC (Frank, Nordic Semi)
*
AOB
Please let me know if you have any additional item that would like to be added to the discussion.
Thanks,
Antonio
Dear all,
with the start of the holiday season in most countries, availability is reduced for delegates normally attending the TSC meeting.
We currently have on the agenda the follow up on the ADAC discussion proposed by Frank (Nordic). We propose this discussion to happen:
*
on the 8th of August (preferred date)
*
on the 1st of August (as a back up date in case interested parties can't attend on the 8th )
Please let us any feedback about the proposal during this week.
Thanks,
Antonio
Dear all,
please find below the notes that I took during the meeting. The TF-PSA-Crypto-Drivers presentation has been shared already. For next month we are still planning to have a similar session for ADAC, still pending the slides to be polished and shared by Frank.
Thanks,
Antonio
Attendees:
David Brown
Antonio
Frank
PJ Bringer
Kangkang
Eric Finco
Janos
Vincent Berthelot (STM)
Julius Werner
Dominik Ermel
Joanna
Ruchika
Lionel
Shebu
Eric F. / David B. --> MCUboot vulnerabilities (5 reports from STM, no disclosure. 1 for which no feedback yet. David V. analysis posted, but no disclosure -> STM requires to understand how to proceed further)
1 was fixed and released (Injection attack)
For a few of them we need to publish disclosure -> Downgrade prevention can be bypassed. Needs to be disclosed as ST needs to position with their customers. David B. I will go ahead and disclose, we can have a SW workaround. Vincent is ok with it. Other ones are disclosed and no blocker on that, there is a way forward.
TF-PSA-Crypto-Drivers discussion
-> Go through the presentation again. TF-PSA-Crypto repo in the context of Mbed TLS 4.0
Ruchika agrees to proposal idea
Janos on technical: the drivers API are still under development, not feature complete. Details for further improvement, tech forum / github -> direction of that will influence the repo proposal as well
repo / vendor focused. Allow for generated and checked in version of driver_wrappers
--> Stabilize the PSA Crypto drivers API (currently it's all internal)
--> PSA Crypto core vs drivers responsibilities
--> Licensing, binary hosting, docs, and configurability
Vincent: Do you plan to propose a transition period in order to let vendor to move?
Plan discussions in TF-M tech forum / Mbed TLS
--> Any license? BSD-3. -> Taken through the board. Standard permissive licenses ok, but more complex case?
--> Build at least, testing possible. Not have code that is left there without testing
--> Proposal idea is welcomed by current providers of drivers
Dear all,
apologies for the delay in getting this out. Please find below the minutes for last TSC meeting and attached both presentations from Akanksha (TF-A / TS roadmap update) and Frank (TF-PSA-Crypto-Drivers proposal).
I also wanted to remind you that the TF-PSA-Crypto-Drivers topic will have a follow up in the next TSC meeting (20th of June), as last time we did not have any time for discussion and we had to rush the last bits of the presentation, so we're aiming to do a replay / discussion focused session this time: I'd like to invite any interested party to review the material before the meeting.
* TF-A and Trusted Services roadmap
* Proposed collaboration on maintenance / further development of ADAC. @Frank Audun – are you available for this?
* Also, hosting PSA Crypto Drivers
Present:
Dan Handley
Antonio
Akanksha
Anton
Matteo
Eric Finco
Maulik Patel
Kankkang Shen
Camille Greusard
Olivier Deprez
Shebu
Joanna
Frank Audun (Nordic)
Dominic Ermel
Julius Werner
* Akanksha and Dan presented these slides
* More non-Arm Hafnium contributions than previously.
* Eric: Who from?
* I believe Nvidia
* Release 2.11 should be available next week.
* Olivier: TF-A v2.11 trees were tagged today. Release announcement is imminent, worst case next Tuesday!
* GIC v3.3 NMI DI/II gated on some kernel investigations
* Frank presented these slides
* Calling from Ireland
* 1st topic is PSA ADAC. Also to talk about TF PSA Crypto Drivers
* Question of whether ADAC is properly supported in TF-M. We want this a front-end feature in TF-M
* Dan: How platform specific is this?
* If you have e.g. a standard life cycle and crypto concepts (e.g. PSA Crypto) then can have a common front end.
* Anton: When you say platform RoT, do you mean PSA RoT?
* Yes
* Antiono: The “built in keys” support has been on the Mbed TLS roadmap for some time now.
* Yes, we’ll continue to push for this
Thanks,
Antonio
Hi all
Let me know if you have any topics for this Thursday's meeting. So far we have:
* TF-A and Trusted Services roadmap
* Proposed collaboration on maintenance / further development of ADAC. @Frank Audun - are you available for this?
Regards
Dan.
Hi all
One of the topics for the TSC meeting this Thursday (9th May) was the TF-A / Trusted Services roadmap but our technology manager won't be available. Can we reschedule this (again) to the 23rd May, post Linaro Connect?
We'll wait a day or two for feedback before rescheduling.
Regards
Dan.
Hi all
We currently do have any topics ready to discuss in tomorrow's meeting. The next scheduled roadmap update is TF-A/Trusted Services but our tech manager is not ready to do this tomorrow. Therefore I'm proposing to cancel unless anyone has any urgent topics?
Also, the following TSC is scheduled for 16th May, which is during Linaro Connect. I propose bringing this forward a week to the same time on 9th May. Let me know if you have any issues with this. Also, at the last Linaro Connect, we had an informal TF.org Board/TSC meeting for those present. Is there any interest in doing this again?
Regards
Dan.
