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?
* 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, …)