Hi all
The next TSC meeting is this Thursday (Dec 19). Please let me know if you have any topics you'd like to discuss. Some potential ones are:
* TI welcome
* Continue board discussion on potential TF-funded activities,
* E.g. "Code Development using AI". KangKang - do you want to do this or should we push it to a future meeting?
* Continue board discussion on impacts of regulation like CRA. Eric - do you want to do this?
Also, we're getting close to the holiday season so please let me know if you're available, otherwise I may have to cancel.
Regards
Dan.
Present:
Ilias Apalodimas (Linaro)
Antonio De Angelis (Arm)
Dan Handley (Arm)
Matteo Carlini (Arm)
KangKang Shen (FutureWei)
Frank Audun (Nordic)
LionelD (ST)
Michael Thomas (Renesas)
Julius Werner (Google)
(Ilias speaking unless otherwise stated)
There have been some activities around stability and working with the latest kernel.
Some work to improve secure data path support. How to deal with encrypted buffers in secure world.
Each vendor has its own way of doing this. Want to provide a common way.
Jens picked this up and is working with kernel maintainers to provide the common solution.
It works with both FF-A and direct SMC APIs.
He'll be sending v3 kernel patches next week. This should be merged soon.
fTPM:
Microsoft previously had 2 repos to support OP-TEE TA fTPM; a ref TPM library and an OP-TEE TA.
The latter is no longer available, so Linaro are going to host this alongside the other OP-TEE repos.
OP-TEE secure storage was previously under control of the kernel. It relied on a userspace supplicant to mediate access to RPMB.
That was OK when we needed to access secure storage late in the bootflow.
But there's a problem if you needed this early in the kernel bootflow (before userspace is loaded).
We have moved a big portion of the supplicant code inside the kernel itself.
This works much better than previously.
Lionel: Is it a standalone subsystem that can be used e.g. in UBoot?
Uboot already has direct access to flash.
The problem was early kernel code that needed access before userspace was up
Jens also working on dynamic configuration of OP-TEE for e.g. number of cores, amount of secure memory.
We plan to work on FF-A 1.2. We want this in OP-TEE and Xen.
We think the memory sharing interfaces and other APIs will be useful.
Expect this to land soon.
We're also doing some hardening.
Increasing test coverage, CI improvements , enabling QEMU-sbsa
Secure Partition support:
There's an implicit dependency on thread support, which we're trying to remove
We're thinking about how to launch S-EL0 SPs without an entity in S-EL1 (like Hafnium)
Also support for Logical SPs, which is not supported at the moment
Lionel: Not sure if you're planning to use Device Tree (DT) for the dynamic configuration?
We're trying to base OP-TEE config on DT format
The problem is DT is OP-TEE specific and embedded within the OP-TEE image
Have you thought about adding support for the kernel DT?
Why do we want to pass that to OP-TEE?
Lionel: We already have a number of drivers in OP-TEE. Would be good to be able to discover them.
Lionel: Have already mentioned it to Jens
I haven't discussed this with Jens but it's an interesting idea
Don't think we have a function in OP-TEE to handle DT
Lionel: We have made use of the embedded DT in OP-TEE image but it's not ideal as this is specific to OP-TEE
Could be a security risk.
Lionel: This could use existing support in TF-A
Lionel: Can discuss offline
Suggest using FW handoff protocol, which includes support for DT entries
https://github.com/FirmwareHandoff/firmware_handoff
Would prefer a standard method than every vendor doing their own thing
Dan: Maybe some additional Transfer Entries (TEs) are needed for OP-TEE?
Dan: The preference is to define TEs with specific fields for firmware use rather than generic container formats like DT
Dan: Though using the kernel DT in firmware is fine.
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.
