Shebu Varghese Kuriakose (Arm)
Antonio De Angelis (Arm)
Dan Handley (Arm)
Janos Follath (Arm)
Eric Finco (ST)
Lionel Debieve (ST)
P J Bringer (ProvenRun)
Michael Thomas (Renesas)
Julius Werner (Google)
Moritz Fischer (Google)
Dominik Ermel (Nordic)
Mbed TLS roadmap (Shebu)
* Shebu presented roadmap (attached)
* Looking to align TF-M and Mbed TLS LTS releases (every 18 months), 3 year lifetime
* TF-PSACrypto repo expected end of this year or early next year.
* Still features to be added to PSA Crypto to have feature parity with legacy Mbed TLS APIs
* But there's enough now to switch to PSA Crypto as the default
* Original scope of 4.0 release was to remove all legacy interfaces while supporting all features provided by legacy interfaces
* Some rescoping needed to get release out
* Some features provided by legacy interfaces will only be available in subsequent TF-PSACrypto 4.x releases
* 1st half of 2025 is all about MBed TLS 4.0 prep
* We'll look at other features 2nd half of 2025.
* Hopefully TF-M and other consumers will move to TF-PSACrypto 4.x in 2nd half of 2025
7 year TF-A LTS (Dan)
* Request from Chris Palmer (Google Android) to extend TF-A LTS lifetime from 5 years to 7 years
* Currently a community effort from Arm, Google, Nvidia and ST.
* Obviously there's a cost to supporting up to 7 concurrent LTS for longer than before
* Arm's position is that we're willing to increase our own efforts if others are too. Can't do it on our own.
* Not really a cost to TF.org, other than the extra CI cloud cost.
(No concerns raised by others)
Firmware_handoff lib hosting (Dan)
* https://github.com/FirmwareHandoff/
* Originally an Arm spec but became a community effort as it became clear this is about alignment across SW projects rather than a need for central standardization
* Still at v0.9 but expect to be able to make a v1.0 release soon.
* There are already implementations in U-Boot, TF-A and OP-TEE
* There's a common library implementation that we expect to at least be used by the latter 2, maybe U-Boot too eventually
* Needs a hosting location. Stakeholders happy for this to be TF.org.
* Proposing this to be under the \shared namespace in git.trustedfirmware.org.
* For maximum compatibility, we're proposing a dual license of GPLv2 + MIT, or possibly GPLv2 + BSD-2-Clause.
* However, as this is not BSD-3-Clause, it will need board approval (as per the charter).
* Julius/Eric: Sounds OK
(No other concerns raised)
Action: Dan to send a mail to the board to try to get this approved offline
OpenCI hosting (Shebu)
* Effort to move OpenCI from Linaro hosting to Arm
* Has been discussed a lot at the board
* Arm has agreed to fund this directly.
* Board farm and FVP hosting will remain in Linaro
* Jenkins and other CI parts will move to Arm AWS instance.
* TF-A, TF-M and Hafnium will be in staging this quarter, public trials expected in Jan/Feb
* Will have fallback to Linaro CI for some time.
* Will allow us to fund more projects in CI, e.g. TF-RMM
Hi all
The agenda for tomorrow's TSC so far is:
* Mbed TLS roadmap update (Shebu)
* Extending TF-A LTS lifetime to 7 years (Chris Palmer)
Please let me know if you have any other topics.
Regards
Dan.
Hi all,
At Google, we are now promising 7 years of support for Pixel devices
<https://store.google.com/intl/en/ideas/articles/newest-pixel-updates/>. We
therefore wonder what it would take to increase the LTS maintenance
lifetime to 7 years (from, I believe 5): resources, project planning, other
things? Can we put this on the agenda for the next board meeting?
Present:
Shebu Varghese Kuriakose (Arm)
Antonio De Angelis (Arm)
Anton Komlev (Arm)
Joanna Farley (Arm)
Frank Audun Kvamtro (Nordic)
PJ Bringer (ProvenRun)
Julius Werner (Google)
Ruchika Gupta (NXP)
Eric Finco (ST)
Lionel Debieve (ST)
David Brown (Linaro)
Shebu presented TF-M roadmap (attached)
* TF-M v2.1.0 released
* Has been in planning for a while
* Main feature is this is the first LTS release
* RTOS projects can pick up aligned Mbed TLS and TF-M LTS releases
* Have worked with Nordic and others to align PSA Crypto headers with ones used in Mbed TLS
* TF-M v2.1.1 LTS in planning
* Main feature will be PSA L2 security certification (originally intended for previous release)
* Anton: Expecting this to pick up MBed TLS 3.6.1
* Eric: Previous idea was to engage with partner Lab. Is that still the case?
* Aligning with TrustCB primarily as that is recommended by PSA Certified
* Riscure will be doing initial evaluation and then TrustCB will be doing subsequent delta evaluations
* Have been doing significant enhancements to Runtime Security Engine (RSE), an Arm TF-M platform
* Anton working on using open source LLVM
* Anton: Front-end will use GNU compiler but LLVM backend, so should be easy to move over
* Anton: Think we can enable this in the next quarter
* Have had a number of requests for this
* Anton: Latest release has full support for Armv8.1-M architecture features
* Then we will have GCC, IAR and LLVM support
* Currently we use a fork of t_cose in TF-M. Want to use upstream version
* Need to change image encryption functionality to use PSA crypto before moving to Mbed TLS 4.0
* Frank: Sorry on a train, so don't want to speak too much. Just letting you know that we have been having some challenges with TF-M build system and will propose that there is a refactoring of this, which can be done by introducing TF-PSA-Crypto as a self-contained PSA Core.
* Anton: Frank promised to share more details and then we'll take it forward.
* Dan: Might see a temporary code size impact moving to Mbed TLS 4.0
* TF-M won't see that but still might get an improvement later.
(Dan later: Apologies, I got my wires crossed with code size issues in TF-A when moving from legacy crypto API to PSA crypto API on an earlier Mbed TLS version)
Antonio: For ADAC, we will need to add a work item to move API that ADAC uses to PSA Crypto, likely H1 25.
Ruchika: You mentioned Mbed TLS 4.0, do you expect a preview for that. Haven't seen much activity yet.
Shebu: A lot of work going on in the background.
Shebu: Want to make TF-PSA-Crypto a live repo where you can see ongoing development. Plan is before end of year.
Shebu: Will be a precursor to MBed TLS 4.0.
Ruchika: When we integrate PSA Crypto with TF-M we have integration problems. We have to do a lot of manual integration work.
Antonio: Still on our plan to do auto generation script.
Ruchika: It's difficult managing this for several repos.
Antonio: Agree. This hasn't been prioritised yet because it's not broken. But I agree it's not ideal
Dan talked about fTPM enablement:
* Background is that in discussion with partners and Arm's architecture group, we think the importance of firmware TPMs (fTPMs) is increasing.
* Also, the OP-TEE integration code that is hosted by Microsoft along with the reference C implementation seems to be deprecated and may be removed.
* Linaro have agreed to host this integration code along with their other OP-TEE repos (in GitHub).
* There's also some outstanding work to make this work properly, e.g. to leverage the Global Platform crypto library
* This is subject to LEDGE approval but don't expect any issues as it's not a lot of work
* At the same time, Arm will pick up Trusted Services FF-A fTPM implementation (again based on the MS TPM reference code)
* This will work with either Hafnium SPMC or OP-TEE SPMC
* There are some issues regarding what crypto library to use.
* The WolfSSL integration is not suitable for our reference platforms due to the license
* Ideally we'd use PSA Crypto but the simplest integration relies on BigNum interfaces, which are internal to PSA Crypto.
* We also need to intercept work going in OP-TEE and Linux to refactor the supplicant interfaces and use an RPMB driver in Linux
* Once this is all working, Arm reference platforms and OneLab platforms can leverage these implementations
* Shebu: We want to let everyone know what we're doing here
* Shebu: We know people are already using the OP-TEE TA config so want to give a heads up this is moving to TF.org.
* Shebu: It would be good to know if people are interested or want to contribute.
* Shebu: For now this will fully rely on MS reference library.
* There's a potential backlog of other stuff we can do but that is dependent on the above basic enablement and pull from partners
* For example, we could add abstractions for sharing access to secure storage if there are multiple use-cases for access
* Or even replace the MS TPM reference with a lighter library written in a memory safe language, e.g. Rust. But we wouldn't embark on that lightly
* David: FYI Zepyhr approved use of Rust for modules
LTS for MCUboot
* Dan: Now there are LTS for Mbed TLS and TF-M, we might need the same for MCUboot
* David: Agree we might need to define tagging policy and when to backport fixes.
* David: Over lifetime of MCUboot have had maybe 10 patches to backport
* Antonio: This was originally raised by Frank
* Antonio: Makes sense to have LTS version that goes into TF-M
* Antonio: Could have same policy as TF-M
* David: Makes sense to piggy back on something
* David: MCUboot is currently driven by TF-M or Zephyr.
* Antonio: Not sure why but Zephyr release was picking up tip of TF-M
* David: There was something that was considered an internal API but was actually used externally and so we had to coordinate releases of TF-M and MCUboot
* Frank: I do recommend MCUboot defines a process for this
* Frank: MCUboot is actually a toolset for a bootloader, not a boot rom. So it's hard to define the supported APIs.
* Dan: Can we just review the TF-M policy and see if this (or a subset of it) can be used for MCUboot?
https://trustedfirmware-m.readthedocs.io/en/latest/releases/release_process…
* Dan: David, can you read this and we can discuss this next time?
AOB
* Karen Power taking over from Don Harbin as TF.org community manager
* There will be a transition over the next couple of months.
* She's already active in the OpenCI work.
* Need to invite her to this call!
* Some modest budget surplus is projected to be available at the end of year.
* Let us know if there are any ideas for how to use this (e.g. extra testing, external evaluation, tooling, ...)
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
