Dear all,
Please find below the minute of the meeting for yesterday’s TSC; also the presentation is attached.
Attendance:
Shebu
Joanna
David
Janos
Antonio
Eric Finco
Andrew Davis
Julius Werner
PJ Bringer
Dominik Ermel
David Brown
Frank AK
Michael T
Agenda:
* TF-PSA-Crypto / Mbed TLS roadmap update [Shebu]
*
Zephyr’s release timeline and sync with dependency projects (TF-M, Mbed TLS, TF-PSA-Crypto) [David B]
[Shebu] TF-PSA-Crypto release and split happened in 2025, April 2026 targeting for first TLSs to be integrated with TF-M
PSA Crypto APIs are now the default APIs
PQC algorithms: After NIST ha standardised, we’re looking into how to enable PQC into PSA Crypto. First step is ML-DSA; start with mldsa-native from PQCAlliance. Fork and integrate through the PSA Crypto drivers interface ML-DSA-87 initially only. PSA API in the work. TF-M will pick it up as soon it is available. Then look into ML-KEM. Hopefully it will be adopted widely
[David B] What’s the timeline? PR already open, driven by Gilles. Integration in drivers first; might not make it into the LTS but should available by April; Then PSA APIs support will happen towards end of Q2
[Shebu] Appreciate any feedback upstream
[Shebu] Arm Bug Bounty project has been rolled out. Lot of interest and traction; Several submissions and security incidents reported.
[Shebu] tf-psa-crypto-drivers interest from partners to maintainer vendor drivers; Mbed TLS or TF-PSA-Crypto doesn’t maintain drivers because there is no way for testing. CryptoCell goes first
[Shebu] Additional maintainer from the community: Valerio Setti from Baylibre contracted by Nordic Semiconductor. First maintainer from non-Arm. Hopefully sets a good precedence for more contributors to be involved in the project, for example security engineer from partner companies doing more reviews as Mbed TLS / TF-PSA-Crypto is always scarce on review bandwidth.
[Frank AK] NXP requests on driver API change for KDF. Oberon has a proposal, our understanding is that Oberon has intention to push that proposal on PSA API Github after following up on discussion on Discord, Andrew T happy to review the proposal so at the moment we’re waiting for Oberon to push the proposal. Also we are happy to have partner companies, implement those APIs based on the Oberon proposal
[Frank AK] The proposal is still limited to non-opaque keys, so this needs more discussion towards either NXP or Arm to complete / fulfill the discussion.
[Shebu] The first step would be to wait for Andrew T come back from holiday, wait for push, and then discuss on Github and the tf-psa-crypto-drivers working group; Janos agrees on discussion for the tech aspects in that, then feedback into API proposal to finalise the API submission
[Janos] On Security issues and Reviews: new bug bounty program resulted in quite a number of vulnerabilities, some of them have merit, a lot of analysis and bandwidth consumption for the team; Think AI tools are helping to submit more vulnerability reports. As a comparison, previously we were getting 1-3 reports, last week only we got 5. Non-negligible time for the maintainers to review, not very predictable. Can affect delivery times overall.
[Janos] OSTIF Audit offered to us and decided to go through with it
[Janos] Process to support community members to become trusted reviewers. Likely being a trusted reviewers is a pre-requisite to push features that are not on the roadmap, community-driven. Power that can be use
Thanks,
Antonio
Sent from Outlook for Mac
Dear all,
we are restarting the TSC meetings from tomorrow with the roadmap updates. @Shebu Varghese Kuriakose<mailto:Shebu.VargheseKuriakose@arm.com> and @Janos Follath<mailto:Janos.Follath@arm.com> will give an update on the TF-PSA-Crypto / Mbed TLS projects roadmaps.
Agenda:
*
TF-PSA-Crypto / Mbed TLS projects roadmap updates
*
Any other business
Please reply to this email if you want to add a topic to discuss for the meeting.
Thanks,
Antonio
Hi all
I apologise for the late notice, but today’s TSC meeting is cancelled as we haven’t managed to prepare for this properly. Hope to speak to you in February. Let me know if you have anything more urgent to discuss.
Regards
Dan.
Hi all
Apologies for the delay, but here are the minutes from the last TSC:
Present:
Dan Handley (Arm)
Antonio DeAngelis (Arm)
Bharath Subramanian (Arm)
Eric Finco (ST)
Kangkang Shen (FutureWei)
David Brown (Linaro)
Julius Werner (Google)
Dominik Ermel (Nordic)
Michael Thomas (Renesas)
Bharath presented the TF-A roadmap (attached)
This is mainly about enablement of the 2023-2024 architecture extensions
Eric: Is Rust SPMC something new for the Rust project?
Dan: No, we're just taking the previous Rust SPMC prototype project and turning it into a library for reuse in RF-A and potentially other projects too.
Bharath: Dan - do you want to say something about TF-RMM?
Dan: Just that TF-RMM (and Linux kernel guest) has CCA 1.0 support upstream, but Linux host upstreaming has been delayed a long time.
Dan: Due to this and KVM maintainer feedback, we're planning some significant changes to the CCA roadmap.
Dan: This requires some replanning - we'll give a more comprehensive CCA update in a future session.
KK: I went to OSFC conference
KK: It was a good 1 week conference. The presentations are online
KK: We are sponsors so I got a ticket!
Dan: Any particularly interesting sessions?
KK: One from Microsoft about TF enablement but you have to be UEFI member to see it.
KK: Also asked Microsoft guy if he would present this at TF.
KK: I will send contact details.
Dan: Also, note there will be an update on some important changes at Linaro at the next board meeting.
Julius: Is that board meeting the earlier one?
Bharath: Yes
Julius: Will it be recorded?
Bharath: We can ask for that bit at least to be recorded. Will also ask Bill to distribute the slides.
Bharath: There's a TF budget surplus so we're asking if there are any suggestions on how to spend this?
(no response)
All,
Please be aware that today we have published our AI policy with Guidance on
AI-assisted contributions.
See the full details here: https://www.trustedfirmware.org/aipolicy/
Should you have any questions feel free to raise them.
Thanks,
Shaun
Community Manager
Hi all
Let me know if you have any topics for tomorrow's TSC meeting. I don't currently have any so will cancel if there are no replies to this by the end of today (all timezones). I did want to restart the roadmap updates but the Arm tech managers are unavailable this week.
Regards
Dan.
Present:
Dan Handley
Antonio De Angelis
Eric Finco
Yann Gautier
Frank Audun Kvamtrø
Olivier Deprez
Manish Pandey
Manish Badarkhe
Javier Almansa Sobrino
Julius Werner
Kangkang Shen
Arunachalam Ganapathy
Michael Thomas
Varun Wadekar
Joanna Farley
Agenda:
1. Progressing the TrustedFirmware.org "Guidance on AI-assisted contributions"
2. More information on the proposed TrustedFirmware.org bug bounty program.
3. Debrief of OSFC call on EU-CRA boot managers
Progressing the TrustedFirmware.org "Guidance on AI-assisted contributions"
Dan recapped previous discussions at board and TSC (see attached).
Eric's feedback on the draft policy:
* Explicitly attribute the tool used for the contribution for transparency
* Policy should apply to all projects of TF.org rather than having project-specific guidance
Some pushback from TF.org members on these modifications. Wider feedback requested from maintainer community
How do we proceed?
Example feedback:
* Hard to gather attribution information when using some high level AI tools. The tools may be seamlessly integrated into a developer's IDE.
* Projects might be risk averse and want to define their own policy instead of having to apply the wider TF.org policy
Kangkang shared his experience when using AI assisted tooling. For open source the there are lots of models available and they're evolving quickly. They're very flexible and quick at producing code. Main issue is verification of the code that is being produced; that should be done by a real human. Suggest contributors are responsible for what they contribute, whether they use AI tools or not.
Dan: There's no issue with the value of using the tools and that contributors are responsible for their contributions. But this meeting is about defining the policy and handling any feedback.
Eric: Often we identify problems that need to be debugged so we believe it is fair for the maintainer to be informed about which tool has been used.
Olivier: Are you asking for hints in the commit message that portions use such tools?
Olivier: Or more fine grained saying specifically what tool?
Eric: Both, although I agree with KK it will be hard to provide accurate information.
ManishB: What is expected of these attributions?
Dan: Just an indication to reviewers.
ManishB: Might be hard to trust these attributions.
Joanna: Don't think attributions are needed when contributions already must comply with the DCO.
Joanna: I like the policy as shown in the draft. Would want to allow projects to extend the guidance, though not to allow them to deviate.
Varun: As a downstream consumer, I would find attribution info useful.
Dan: OK, we're far from consensus here so I think we need to pass this back to the TF.org board for a vote to proceed.
More information on the proposed TrustedFirmware.org bug bounty program.
Dan presented attached slides
MCUboot could be added to the list of qualifying projects if it adds a threat model.
Expect TF-RMM and Hafnium to be added in due course too.
No objections or feedback received so propose that Arm proceeds with this and we have a final check in before it goes live.
Debrief of OSFC call on EU-CRA boot managers
Eric described his takeaways from the OSFC call in August
Eric: What is new is that EU-CRA is to work on a set of standards (Working Groups (WGs) in ETSI). 18 different WGs.
Eric: They're expected to produce standards that are conformant with CRA.
Eric: If you look at the publicly available groups, I see at least 2 WGs that are relevant for TF.org; one is boot manager, other is hypervisor.
Eric: The TF.org Board was contacted by OSFC and the boot manager WG chair. They wanted to advertise their work and asked us to contribute.
Eric: Outcome wasn't very obvious. Not sure what they want to standardize.
Eric: In CRA, there is a distinction between open source stewards and product manufacturers. But no idea what these 2 WGs mean for TF.org.
Eric: ST will keep an eye out. Will try to find people to get involved in these WGs. Would welcome any contribution from others.
Olivier: Agree with this summary.
Olivier: The discussion started on boot managers but became more general. What CRA means for open source stewards.
Olivier: There might be pressure from manufacturers to upstream fixes to problems.
Olivier: There was an example in uboot and how it's integrated into distros. But manufacturer remains responsible.
Eric: Specs were actually written about a year ago. So better to be involved earlier before they become stable.
Eric: There are other groups on OS, PKI, etc...
Dan: Would be good if ST keep TF.org board informed. Will try to get Arm involved and we can assess if others should be too.
Eric: As background, there's a good presentation from Linx Foundation's Kate Steward at OSS25 using Zephyr as example: https://static.sched.com/hosted_files/osseu2025/32/202508%20OSSEU%20Zephyr%…
Eric: Also see ETSI - CRA Standards Unlocked - Opening public consultation
https://www.etsi.org/events/2586-crawebinar
Will be open for public feedback soon
Hi all
I currently have 2 topics for this Thursday's TSC meeting:
1. Progressing the TrustedFirmware.org "Guidance on AI-assisted contributions"
2. More information on the proposed TrustedFirmware.org bug bounty program.
For 1, as previously mentioned I'm inviting a representative subset of project maintainers to gather their feedback. I will forward the meeting invite. If you cannot make the meeting but would like to give feedback, then please reply to the thread I started on 2025-07-31 with the subject "Feedback requested on TrustedFirmware.org "Guidance on AI-assisted contributions"".
For 2, given this would be an Arm funded initiative, it's not clear to me if we need to seek formal TrustedFirmware.org TSC/board approval. We can discuss in the meeting.
Let me know if there are any other topics you'd like to discuss.
Regards
Dan.
Hi all
I've sent this to what I hope is a representative subset of TrustedFirmware.org project maintainers. Feel free to forward to others you think should be included.
I'm writing to gather maintainer feedback on a proposal for TrustedFirmware.org to have a policy on the use of AI-assistants in code contributions. Several other open-source organizations already have their own policies. Attached is the current draft of that policy, which is based on the Linux Foundation and Apache Software Foundation guidance. This has been discussed at the TF.org board and more recently, the TSC (see minutes here<https://lists.trustedfirmware.org/archives/list/tsc@lists.trustedfirmware.o…>). Eric Finco @ ST had 2 pieces of feedback to this, the 2nd of which prompted me to seek this wider input. To summarize that feedback:
1. Eric would like all contributions that use AI assistants to explicitly attribute the tool(s) used in the contribution for transparency reasons. The counter feedback is that this might be onerous to generate (especially if a tool has a complex backend) and there is no clear use for that information.
2. Eric would like the policy to apply to all TrustedFirmware.org projects, rather allowing projects to develop their own project-specific guidance (as per the current draft).
Some of this might require more interaction discussion. My plan was to invite you all to a future TSC meeting (perhaps in September) to discuss further. I'm happy to take feedback on the policy, Eric's feedback or the process to handle this. Feel free to reply to this email (to all or just to me), or just wait for that TSC meeting.
Best regards
Dan.
HI all
We have a TSC meeting scheduled for this Thursday 2025-08-21 but I'm not sure if there will be enough people available due to holiday/vacation. Please could you reply to me if you are available. If there are not enough people, I will cancel. Note, the board meeting is cancelled this month.
Possible topics include:
* Wider discussion on AI code generation policy with invited maintainers.
* More details on Arm's proposed bug bounty program for TF projects.
Regards
Dan.
Present:
Dan Handley (Arm)
Shebu Varghese Kuriakose (Arm)
Joanna Farley (Arm)
Eric Finco (ST)
P J Bringer (ProvenRun)
KangKang Shen (FutureWei)
Andrew Davis (TI)
Dhruva Gole (TI)
Kamlesh Gurudasani (TI)
Agenda:
* Feedback on draft guidance for AI contributions (see board thread<https://lists.trustedfirmware.org/archives/list/board@lists.trustedfirmware…>)
* Discussion on the CRA topic (see last board thread<https://lists.trustedfirmware.org/archives/list/board@lists.trustedfirmware…>)
Shebu: Hopefully everyone has seen the draft AI code generation policy I sent
Shebu: Eric - can you summarise your feedback?
Eric: 2 things. One, can we signal that the contribution has used an AI assistant?
Eric: One reason is the EU act recommends transparency. We (ST) also believe transparency is a good reason.
Eric: Other feedback is we don't see a strong reason to allow projects to deviate from policy.
Eric: Think it would be more consistent to have same policy across all TF.org projects.
Shebu: On 1st item, is the signal to the maintainer or the consumer?
Eric: Primarily to the maintainer.
Shebu: We looked at Linux Foundation, Apache and other policies. Apache does recommend it's generated by a particular tool.
Shebu: But people can still decide not to put in attributions.
Shebu: Should attribution be in the patches themselves (commit messages) or some separate message?
Eric: No strong opinion on this. Either works. More widely available if it's in the commit message.
Shebu: No consortium is mandating this. Only 1 is recommending it.
Eric: Agree it's hard to enforce. Would just be declarative.
Shebu: The primary concern of other consortiums was that the contributor is responsible for where their contribution comes from.
Shebu: Not sure if having the attribution implies we'll do something with those attributions?
Eric: Would just be informative information.
Eric: Agree it's up to the contributor to take responsibility
KK: AI is moving very fast. We really don't know where people got the code.
KK: We have to be clear it's the contributor that is responsible.
KK: I just went to Confidential Compute conference.
KK: Everything was about AI, e.g. Agentic AI
KK: Most companies are concerned about not releasing their confidential information.
KK: If you're working in the open world, you don't have that risk. Need to have that separation.
KK: There are many companies using many different tools. Rule needs to be as simple as possible.
KK: OpenAI CEO thinks AI coding will be pervasive by the end of the year.
KK described other leading edge developments in the world of AI, e.g. agentic assistants.
Shebu: So do you (KK) think we should avoid attribution.
KK: Yes, we shouldn't care where it come from. It may be hard to gather all the details on how the patch was generated.
Shebu: No policies so far have suggested changes to DCO or other contribution terms.
Shebu: Agree that if someone is using agentic assistant, then attribution may be hard to produce.
KK: A bunch of AI engines may have been involved in the development workflow. Not a one-shot thing.
Shebu: Best we could do is a recommendation. But we wouldn't want to limit contributions because of this.
Shebu: Could having this cause a misconception that the code is fully auditable?
KK: Even in current workflow, if multiple engineers contribute, the final committer takes overall responsibility.
Shebu: Can follow this up at the board meeting.
Shebu: 2nd piece of feedback was about having a global TF.org policy
Shebu: Again, this option for projects to deviate came from the Linux Foundation guidance.
Shebu: This policy has only been reviewed by board and TSC
Shebu: Project maintainers may have different opinions. We haven't asked them yet.
Shebu: Difficult to assess as there is a large community of maintainers across all projects.
Dan: We certainly would need to get more maintainer buy-in if we removed this option to deviate.
Dan: We want to get their feedback anyway but especially important if we're trying to force this on them.
Dan: Any thoughts on how we should gather that feedback?
KK: Just ask all the maintainers
KK: Used to be able to write ~10 LOC/day. Now can do much more, especially for example test suites.
Joanna: If you have a big maintainer pool, might not get much response.
Joanna: Suggest getting a smaller pool or approaching each project individually.
Dan: OK, will wait for outcome of board meeting then send latest draft and open issues to (some) project maintainers.
Dan: Eric last month sent some interesting links on CRA implications/recommendations
Eric: CRA has recommendations around security policy and SBOMs.
Eric: Also, something around auditing (including SBOMs).
Shebu: Looking at those materials and recent Linaro Connect materials, should we start looking at SBOM generation at TF.org?
Shebu: Or wait for more developments/requirements?
Eric: One thing we could discuss is settling on SBOM format (CycloneX or SPDX).
Dan: And tooling to use?
Eric: Afterwards, yes.
Dan: Should we be doing more in terms of integration at TF.org (e.g. using Yocto) rather than devolving this to component projects?
PJ: Eric - are you aware of similar projects and the format they chose?
Eric: Think Yocto and Zephyr are using SPDX (would need to double check).
PJ: I could investigate this offline.
Dan: Yes, thanks!
KK: Companies that use TF.org take final responsibility for accuracy.
KK: They can't trust TF.org to have done the right thing and TF.org shouldn't take responsibility.
KK: But it's good if TF.org can help avoid duplication by companies.
Present:
KangKang Shen (FutureWei)
Eric Finco (ST)
Dominik Ermel (Nordic)
Julius Werner (Google)
Michael Thomas (Renesas)
Bharath Subramanian (Arm)
Dan Handley (Arm)
Dan: Not many attendees today so expecting a short call.
Dan: Just a few small topics...
Gauging interest in a Hafnium LTS
Dan: Following the success of the TF-A LTS, NVidia have requested that we also create a Hafnium LTS
Dan: NVidia and Arm are willing to contribute to the maintenance of this.
Dan: Are there any other TF.org members interested in this, or are there any objections?
Eric: No interest from ST
(No other comments. We'll assume this can be progressed at the project level)
Status of Firmware Handoff spec and libTL reference implementation
Dan: We've been working to close out the remaining blocking issues to release v1.0 of the firmware handoff spec.
Dan: These are now resolved and there is an open PR to make the version 1.0 (https://github.com/FirmwareHandoff/firmware_handoff/pull/72).
Dan: The corresponding libTL is now available (https://git.trustedfirmware.org/plugins/gitiles/shared/transfer-list-librar…).
Dan: This is not yet used by other TF.org projects so won't be in the upcoming TF-A v2.13 bundle release.
Dan: There's work ongoing for projects to migrate their use of their own FW handoff implementations with libTL.
(Later: Will be discussed in this Linaro Connect session: LIS25-318 Firmware Handoff specification and Transfer List Library development<https://www.kitefor.events/events/linaro-connect-2025/submissions/404>)
(No comments)
Linaro Connect planning
Dan: Will anyone be going to Linaro Connect?
Dan: Bharath, myself and and others from Arm are going if anyone would like to meet.
(Later: A "TrustedFirmware.org Drop-in Room" meeting has been arranged at 14:00 on May 14.)
(Later: Also see the session: LIS25-114 Trusted Firmware Project updates<https://www.kitefor.events/events/linaro-connect-2025/submissions/288>)
(No comments)
Any further discussion on TF.org AI code generation policy?
Dan: The result of the vote in the board meeting was to proceed with developing some guidance that allows code contributions to TF.org projects that use AI tools.
Dan: Shebu is currently drafting something based on the existing Linux Foundation and Apache guidance that will be reviewed by the board.
Dan: Does anyone want to discuss this further in the TSC?
Eric: ST is fine with this plan.
(No other comments).
Dan:AOB?
(None)
Hi all
Let me know if you have any topics for tomorrow. I have a few small items:
* Gauging interest in a Hafnium LTS
* Status of Firmware Handoff spec and libTL reference implementation
* Linaro Connect planning
* Any further discussion on TF.org AI code generation policy?
Regards
Dan.
Dears,
apologies for the short notice, but having no agenda for today and no planned roadmap update as well, I propose to cancel the meeting also in view of a lighter expected attendance due to to Easter holiday period.
Apologies again for the short notice,
Thanks,
Antonio
Present:
Antonio De Angelis (Arm)
Bharath Subramanian (Arm)
Dan Handley (Arm)
Dominik Ermel (Nordic)
Pierre-Julien Bringer (ProvenRun)
Michael Thomas (Renesas)
Andrew Davis (TI)
Julius Werner (Google)
Moritz Fisher (Google)
Ruchika Gupta (NXP)
Eric Finco (ST)
David Brown (Linaro)
Agenda:
* Firmware-A roadmap (Bharath)
* Discussion on use of AI tools for code generation at tf.org
Action from last time:
Antonio:: We shared the TF-PSACrypto-Driver repo
Antonio: Gerrit permissions should be set up
Antonio: Let me know if any issues
Firmware-A roadmap (Bharath):
Bharath presented attached slides
Dan: Clarification: Arcadia CPU is Cortex-A320.
Eric: When is MbedTLS 4.0?
Antonio: Planned in September. TF-A release after that will pick it up.
Dan: The FW-handoff spec is close to reaching its 1.0 release (just closing out final PRs).
Dan: The corresponding libTL reference library has all the approvals it needs and will be pushed to TF.org Gerrit very soon.
Discussion on use of AI tools for code generation at tf.org:
(Dan presented the slides on the use of AI generated code at Trusted Firmware.org, attached to last month's minutes)
Dan: Already discussed at board but seeing if there's any further input at TSC.
Dan: The plan is to for board/TSC reps to find out their company position on using these tools for code generation.
Dan: This is separate to the use of AI tools for other purposes, e.g. code review, debugging, ...
Dan: A non-binding poll will be sent out to find out whether members think TF.org should be broadly in favour of using these tools, broadly against using these tool, or think we can remain neutral (no official policy).
Dan: Once we know the general direction we can refine this into a specific policy, perhaps leveraging other organization's policies.
Dan: At the same time we should privately gather the opinion of the projects' core maintainers to ensure alignment.
(rest of conversation redacted)
AOB:
Julius: Regarding the security vulnerability process
Julius: I noticed some notifications to ESS for CVEs I don't know anything about.
Julius I would like to receive the underlying vulnerability info as Arm PSIRT distribute to a different group in Google.
Dan: This is specifically for workarounds to vulnerabilities in hardware IP.
Dan: There's some conflict due to overloading this process for both SW and HW vulnerabilities.
Dan: The distribution for the latter (Arm IP licensees) does not necessarily match the TF-A ESS/TS list.
Dan: I'm OK with your proposal as long as it's a one-way channel and all questions go to Arm PSIRT.
Dan: I don't want TF.org security people supporting issues with Arm HW IP.
Dan: We'll try to improve this process in future.
Hi all
Let me know if you have any discussion topics for tomorrow's TSC meeting. So far I have:
* A-profile firmware update (Bharath and Dan).
Regards
Dan.
Present:
Dan Handley (Arm)
Shebu Varghese Kuriakose (Arm)
Matteo Carlini (Arm)
Anton Komlev (Arm)
Joanna Farley (Arm)
Antonio De Angelis (Arm)
Ahmad El jouaid (ST)
Michael Thomas (Renesas)
Frank Audun (Nordic)
Dominik Ermel (Nordic)
KangKang Shen (FutureWei)
Kamlesh Gurudasani (TI)
Andrew Davis (TI)
Ruchika Gupta (NXP)
Agenda:
* Continued discussion on TF-M binary hosting (Ahmad)
* Continued discussion on PSA-Crypto Drivers hosting (presented by Frank @ Nordic in May '24 TSC)
* Continued discussion on TF-M code size and impact on PSA certification (this was cut short in the December meeting).
* Discussion on the use of AI assistants (continued from the board meeting).
Continued discussion on TF-M binary hosting (Ahmad)
(Slides sent to list by Eric on 2025-2-27)
Ahmad: Requirement is for binary to be upstream, matching the source code.
Ahmad: Previous request was for this to be in TF-M repo
Ahmad: Dan previously proposed to use the tf-binaries repo
Ahmad: Anton mentioned concerns about repo growth
Ahmad: Size doesn't seem to be an issue (~128kb)
Ahmad: Would be easier for customers to consume if it was in the same repo
Anton: It's not about a single binary size. The entire binary for every platform will be added to the repo for every release.
Anton: Git is not clever enough to only upload deltas in a binary.
Shebu: This would set a precedent. Could be maybe 15 platform binaries (in worst case) for each release.
Shebu: Where in TF-M repo would this live and be advertised? Customer might not see this anyway if it's in a platform directory.
Ahmad: We still prefer the 1st option (slide 4) but could do the 2nd option if needed.
Ahmad: We only see 1 binary in the tf-binaries repo. Is this old?
Dan: It was not used for the original purpose it was created. So it's been dormant for a while but it's still usable.
Anton: Another concern is that other platforms could be ~500KB or more.
(Some agreement this needs discussing further in the TF-M project)
Continued discussion on PSA-Crypto Drivers hosting (presented by Frank @ Nordic in May '24 TSC)
Ruchika: Haven't seen any further discussion on this since then.
Ruchika: We are looking for somewhere to host these. Either upstream or downstream.
Ruchika: What's the latest news?
Frank: We've been discussing with Arm. Haven't progressed to completion.
Frank: Antonio has been working on a prototype.
Frank: It was mentioned in Mbed TLS tech forum.
Antonio: We were first waiting for separate TF-PSA-Crypto repo to be created. That's done now.
Antonio: We want this to be a shared effort with partners
Antonio: Arm can create the repo space and structure for this but need others to fill it in.
Shebu: Mbed TLS team is busy with 4.0 release and first TF-PSA-Crypto release
Shebu: Hoping that Frank will be able to help progress this.
Frank: Yes. Think it make sense for Arm to initiate hosting of this. But don't know exact plans on PSA-Crypto driver API standardization.
Frank: My understanding is that not much is happening here.
Frank: So can we at least tag what we have?
Frank: Think both ST and Nordic will contribute to this.
Shebu: Agree the API is not standardized but it's not changed much so we should tag it.
Frank: Think this is best-effort work for everyone. So tagging is a starting point.
Frank: Have had questions in Zephyr about where to put these drivers.
Frank: Really need to start this effort within the next quarter. Fragmentation potential otherwise.
Frank: Also need to consider Mbed TLS 3.x LTS distribution.
Ruchika: So this interface wrapper would still live in the TF-PSA-Crypto repo? Have seen the driver wrapper has remained constant since 3.1/3.2
Antonio: Yes the wrapper would remain in the TF-PSA-Crypto repo.
Ruchika: TF-M could be first project to adopt auto-generated stuff
Antonio: Agree
Shebu: Can discuss at TF-M tech forum.
Frank: Mentioned before that hosting location of PSA-Crypto driver wrapper doesn't matter - it's the header that's important.
Frank: As long as we can start this process, can figure out the boundary as one of the first things we do.
Frank: Think we're in a good place to do this given things have been stable for a while.
Continued discussion on TF-M code size and impact on PSA certification (this was cut short in the December meeting).
Frank: From standpoint of Bluetooth devices, it's about the "bare bones" of what to enable. The devices we're working with are very small.
Frank: Could do with a write up of what optimization is allowed.
Frank: We're going to have to do this in our docs but maybe TF-M is a better place for such docs?
Frank: Not sure how product-oriented TF-M wants to be in its docs.
Shebu: Previously there was the idea of defining small, medium, large profile devices.
Shebu: We didn't nail it down to something specific like BT
Shebu: We've realized that every device is a bit different so they won't necessarily fit into one of these 3 profiles.
Shebu: Happy to take feedback on whether we want to adopt these profiles or something like it.
Shebu: Just need to have a sane number of profiles.
Frank: One missing thing is regarding the bootloader - e.g. do you want a bootloader that checks signature? What crypto config?
Frank: Think it would be good if core TF-M (not MCUboot) defined what's permitted here.
Frank: Will propose configs to Mbed TLS project but I know those guys are busy so may take time.
Frank: When it comes to BL2, think it's reasonable to say this should use TF-PSA-Crypto repo.
Anton: Suggest this is discussed in TF-M tech forum.
Dan: Actually all these topics are probably best discussed in the relevant forum in the first instance.
Dan: TSC should be an arbitration point when there's disagreement.
Dan: Maybe the tf-binaries topic is one such disagreement. Do we need to have a vote on this?
Dan: Anton - can you try to get consensus on this in the project?
Anton: Yes, I will raise this on the list.
Frank: I'm also concerned about precedent about binaries in the repo.
Frank: Can quickly go from something small to much bigger.
Frank: E.g. may contain dwarf/elf debug info. Can grow very quickly.
Discussion on the use of AI assistants (continued from the board meeting).
Dan: Not much time to discuss this. Is it worth starting?
Joanna: Can you at least say what happened in the board meeting?
Matteo: We presented approaches other foundations/projects have taken (slides attached)
Matteo: Going to be difficult to detect whether these tools have been used and enforce any policy.
Matteo: Question mark on whether foundations should provide tools to help check contributions.
Matteo: Normally left to the contributor.
Matteo: No conclusion at the board. We will do more investigation.
Shebu: It was mainly about kicking off the discussion at the board.
Shebu: Can we get away without a policy or should we document something here?
Shebu: Most of the big foundations have created something.
Dan: I will send the board slides on this to the TSC [done] and we can discuss next time.
Shebu: Another topic could be using AI assistants for purposes other than code generation (e.g. code validation).
KangKang: I know lots of companies that are already using these tools.
KK: I plan to hire an intern to investigate what can be done here but this might take a while to report back.
Hi all
So far I have the following agenda for the TSC meeting tomorrow:
* Discussion on the use of AI assistants (continued from the board meeting).
* Continued discussion on TF-M code size and impact on PSA certification (this was cut short in the December meeting).
Let me know if you want to discuss anything else.
Regards
Dan.
FYI in case you didn’t receive the earlier cancellation. Today’s TSC meeting is cancelled.
Regards
Dan.
-----Original Appointment-----
From: Karen Power via Tsc-private <tsc-private(a)lists.trustedfirmware.org<mailto:tsc-private@lists.trustedfirmware.org>> On Behalf Of Karen Power
Sent: Wednesday, January 15, 2025 2:18 PM
To: Karen Power; Dan Handley; Eric Finco (eric.finco(a)st.com<mailto:eric.finco@st.com>); lionel.debieve(a)st.com<mailto:lionel.debieve@st.com>; kangkang.shen(a)gmail.com<mailto:kangkang.shen@gmail.com>; Antonio De Angelis; Don Harbin; jwerner(a)google.com<mailto:jwerner@google.com>; David Brown (david.brown(a)linaro.org<mailto:david.brown@linaro.org>); davidb(a)quicinc.com<mailto:davidb@quicinc.com>; kangkang.shen(a)futurewei.com<mailto:kangkang.shen@futurewei.com>; frank.kvamtro(a)nordicsemi.no<mailto:frank.kvamtro@nordicsemi.no>; bpeckham(a)google.com<mailto:bpeckham@google.com>; brandon.hussey(a)renesas.com<mailto:brandon.hussey@renesas.com>; moritzf(a)google.com<mailto:moritzf@google.com>; palmer(a)google.com<mailto:palmer@google.com>; afd(a)ti.com<mailto:afd@ti.com>; praneeth(a)ti.com<mailto:praneeth@ti.com>; Ruchika Gupta; Camille Greusard; pierre-julien.bringer(a)provenrun.com<mailto:pierre-julien.bringer@provenrun.com>; dominik.ermel(a)nordicsemi.no<mailto:dominik.ermel@nordicsemi.no>; Andrej Butok; tsc-private(a)lists.trustedfirmware.org<mailto:tsc-private@lists.trustedfirmware.org>; Michael Thomas; kamlesh(a)ti.com<mailto:kamlesh@ti.com>
Cc: Shebu Varghese Kuriakose; Joanna Farley; Matteo Carlini
Subject: [Tsc-private] Cancelled event with note: TrustedFirmware TSC @ Thu 16 Jan 2025 12pm - 12:55pm (EST) (tsc-private(a)lists.trustedfirmware.org<mailto:tsc-private@lists.trustedfirmware.org>)
When: 16 January 2025 09:00-09:55 America/Los_Angeles.
Where: zoom see below
TrustedFirmware TSC
This event has been cancelled with a note:
"Meeting cancelled as not enough time has passed since everyone returned from the holidays. "
Trusted Firmware is inviting you to a scheduled Zoom meeting.
Topic: TrustedFirmware TSC
Time: Feb 15, 2024 05:00 PM London
Every month on the Third Thu, 20 occurrence(s)
Feb 15, 2024 05:00 PM
Mar 21, 2024 05:00 PM
Apr 18, 2024 05:00 PM
May 16, 2024 05:00 PM
Jun 20, 2024 05:00 PM
Jul 18, 2024 05:00 PM
Aug 15, 2024 05:00 PM
Sep 19, 2024 05:00 PM
Oct 17, 2024 05:00 PM
Nov 21, 2024 05:00 PM
Dec 19, 2024 05:00 PM
Jan 16, 2025 05:00 PM
Feb 20, 2025 05:00 PM
Mar 20, 2025 05:00 PM
Apr 17, 2025 05:00 PM
May 15, 2025 05:00 PM
Jun 19, 2025 05:00 PM
Jul 17, 2025 05:00 PM
Aug 21, 2025 05:00 PM
Sep 18, 2025 05:00 PM
Please download and import the following iCalendar (.ics) files to your calendar system.
Monthly: https://linaro-org.zoom.us/meeting/tJYpdO6pqjwtE9ItoYR_-W2AvXKbkkhzuUvg/ics…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fmeeting%2Ft…>
Join Zoom Meeting
https://linaro-org.zoom.us/j/92437147796?pwd=NXd1a1U2eGlnZkNiUTB1T0xnYzB5Zz…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9243714…>
Meeting ID: 924 3714 7796
Passcode: 100152
---
One tap mobile
+16699009128,,92437147796# US (San Jose)
+17193594580,,92437147796# US
---
Dial by your location
• +1 669 900 9128 US (San Jose)
• +1 719 359 4580 US
• +1 253 205 0468 US
• +1 253 215 8782 US (Tacoma)
• +1 346 248 7799 US (Houston)
• +1 669 444 9171 US
• +1 564 217 2000 US
• +1 646 558 8656 US (New York)
• +1 646 931 3860 US
• +1 689 278 1000 US
• +1 301 715 8592 US (Washington DC)
• +1 305 224 1968 US
• +1 309 205 3325 US
• +1 312 626 6799 US (Chicago)
• +1 360 209 5623 US
• +1 386 347 5053 US
• +1 507 473 4847 US
• 833 548 0276 US Toll-free
• 833 548 0282 US Toll-free
• 833 928 4608 US Toll-free
• 833 928 4609 US Toll-free
• 833 928 4610 US Toll-free
• 877 853 5247 US Toll-free
• 888 788 0099 US Toll-free
Meeting ID: 924 3714 7796
Find your local number: https://linaro-org.zoom.us/u/abwnK0XVLY<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fu%2FabwnK0X…>
When
Thursday 16 Jan 2025 ⋅ 12pm – 12:55pm (Eastern Time - Toronto)
Location
zoom see below
View map<https://www.google.com/maps/search/zoom+see+below?hl=en-GB>
Guests
Karen Power<mailto:karen.power@linaro.org>- organiser
Don Harbin<mailto:don.harbin@linaro.org>- creator
dan.handley(a)arm.com<mailto:dan.handley@arm.com>
eric.finco(a)st.com<mailto:eric.finco@st.com>
lionel.debieve(a)st.com<mailto:lionel.debieve@st.com>
kangkang.shen(a)gmail.com<mailto:kangkang.shen@gmail.com>
antonio.deangelis(a)arm.com<mailto:antonio.deangelis@arm.com>
jwerner(a)google.com<mailto:jwerner@google.com>
David Brown<mailto:david.brown@linaro.org>
davidb(a)quicinc.com<mailto:davidb@quicinc.com>
kangkang.shen(a)futurewei.com<mailto:kangkang.shen@futurewei.com>
frank.kvamtro(a)nordicsemi.no<mailto:frank.kvamtro@nordicsemi.no>
bpeckham(a)google.com<mailto:bpeckham@google.com>
brandon.hussey(a)renesas.com<mailto:brandon.hussey@renesas.com>
moritzf(a)google.com<mailto:moritzf@google.com>
palmer(a)google.com<mailto:palmer@google.com>
afd(a)ti.com<mailto:afd@ti.com>
praneeth(a)ti.com<mailto:praneeth@ti.com>
Ruchika Gupta<mailto:ruchika.gupta_1@nxp.com>
Camille Greusard<mailto:camille.greusard@provenrun.com>
pierre-julien.bringer(a)provenrun.com<mailto:pierre-julien.bringer@provenrun.com>
dominik.ermel(a)nordicsemi.no<mailto:dominik.ermel@nordicsemi.no>
Andrej Butok<mailto:andrey.butok@nxp.com>
tsc-private(a)lists.trustedfirmware.org<mailto:tsc-private@lists.trustedfirmware.org>
Michael Thomas<mailto:michael.thomas@renesas.com>
kamlesh(a)ti.com<mailto:kamlesh@ti.com>
shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> - optional
joanna.farley(a)arm.com<mailto:joanna.farley@arm.com> - optional
matteo.carlini(a)arm.com<mailto:matteo.carlini@arm.com> - optional
Invitation from Google Calendar<https://calendar.google.com/calendar/>
You are receiving this email because you are an attendee of the event.
Forwarding this invitation could allow any recipient to send a response to the organiser, be added to the guest list, invite others regardless of their own invitation status or modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>
Dear TSC members,
Find attached the slides presented by Ahmad for ST regarding TF-M binary hosting during December TSC meeting.
Regards,
Eric Finco
[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: logo_big5]
Eric FINCO | Tel: +33 (0)2 4402 7500
MDG | Technical Specialist
From: Dan Handley <Dan.Handley(a)arm.com>
Sent: Monday, January 13, 2025 4:29 PM
To: Eric FINCO <eric.finco(a)st.com>; Ahmad EL JOUAID <ahmad.eljouaid(a)st.com>
Subject: RE: TSC minutes 2024-12-19
Hi Eric/Ahmad
I'd be grateful if you could send the (non-confidential version of the) slides you showed regarding binary hosting.
Regards
Dan.
From: Dan Handley via TSC <tsc(a)lists.trustedfirmware.org<mailto:tsc@lists.trustedfirmware.org>>
Sent: 13 January 2025 15:26
To: tsc(a)lists.trustedfirmware.org<mailto:tsc@lists.trustedfirmware.org>
Subject: [TF-TSC] TSC minutes 2024-12-19
Hi
My apologies for the lateness but here are the minutes for December's TSC meeting...
Dan.
Present:
* Ahmad El Jouaid (ST)
* Eric Finco (ST)
* Praneeth Bajjuri (TI)
* Andrew Davis (TI)
* Antonio De Angelis (Arm)
* Anton Komlev (Arm)
* Bharath Subramanian (Arm)
* Matteo Carlini (Arm)
* Frank Kvamtrø (Nordic)
* Dominik Ermel (Nordic)
* Chris Palmer (Google)
* Julius Werner (Google)
* Moritz Fisher (Google)
Agenda:
* TI welcome
* Continue board discussion on impacts of regulation like CRA. Eric
* TF-M binary uploads (Ahmad)
Dan welcomes TI to TF.org TSC
Praneeth:
Andrew and Kamlash will be TI TSC reps
I will be on the board
We were part of TF earlier, 4-5 years back.
Want to be more engaged again.
Especially interested in OpenCI, TF-A and TF-M
We will talk about topics of interest in future calls.
We're also interested in UBoot, e.g. LTS strategy
We're engaged with UBoot maintainers.
Kamlesh working for 3 years at TI: security and power management
Linux crypto driver, TF-A, U-boot, ...
Will be handling any new development here
Dan: FW-handoff could be one other possible topic of interest. We're working with Simon Glass (UBoot maintainer) on this.
(https://github.com/FirmwareHandoff/firmware_handoff)
Continue board discussion on impacts of regulation like CRA
Eric:
There was a 2 day workshop by Linux Foundation in Amsterdam, 10-11 Dec
Impact of regulation
2 sets of rules in CRA specification: 1 for manufacturers, 1 for open source stewards
For manufacturers, it's reasonably clear. Have to comply with all requirements in CRA
For stewards, it's much more fuzzy:
* Specific to open source
* Responsible for maintaining security standards
ST understanding is there will be 3 workgroups setup to dive into this and influence the EU's finalisation of the spec.
There's also discussion under Global Platform (GP) on the same topic. ST is part of this and monitoring/contributing.
Most likely will have an impact on TF.org.
Agreement at board is to have regular conversations about this.
I think this is something we have to do. They're expecting some deployment as early as 2025.
Don: What's our likely investment here?
Eric: Keep contributing to stewards's role. May need more community management.
Eric: May need more CI. Too early to say
Frank: Does the GlobalPlatform work you mention also include and/or focus on SESIP?
Frank: Or is our focus more broad and generic?
Eric: Don't have an answer right now. Can check with our guy working with GP.
Frank: in Zephyr security committee, there's an ongoing requirement to handle requirements like these (also for US, Asian markets).
Frank: Unfortunately likely to be many levels removed from the workshop scope. So anything we learn there will be very valuable.
Frank: Thanks to ST for covering this.
Binary hosting topic (Ahmad):
Presented slides
Eric: We will send declassified version of the slides
Will be using our own boot stage (BL2 equivalent) so will only be publishing TF-M secure/ns apps
Export control problems with hosting own boot binary
Would like TF-M binary to be hosted with TF-M repo for ease of integration
Dan: Would it have a different license?
Eric: No
Dan/Julius: Can't we just use the tf-binaries repo?
(https://git.trustedfirmware.org/plugins/gitiles/tf-binaries/+/refs/heads/ma…)
Eric: Requirements are slightly different.
Would like to keep with platform port in TF-M source code
Dan: How to link precise source code version with the binary?
Eric: Maybe could sign binary with SHA-1.
Could have several versions in the repo.
Antonio: Is this for just new platforms or existing platforms too.
Eric: Just new platforms.
Anton: Concerned about side-effect of repo growth.
Anton: Why not host separately and keep link to TF-M source code?
Eric: Haven't discussed repo growth
Eric: Can we limit to release versions?
Ahmad: Yes, can do that and update with each release
Dan: Repo growth is not a blocker issues on its own. Can use tech like Git LFS (https://git-lfs.com/).
Frank: Could tf-binaries be a staging area for this?
Frank: Agree that releasing binaries is a good use-case
Frank: Could ST look into that?
Anton: I accept the use-case but also would prefer to use tf-binaries.
Eric: Next steps. Should we post something on TF-M forum
Anton: Happy to discuss in TF-M tech forum.
Frank: It might also be useful to store other artefacts to that separate repo.
Frank: We also do not use TF-M BL2. We have our own version. But it's still part of certification scope
AOB:
Call for ideas to use tf.org surplus
TF-M code size:
Frank: Nordic also cater for small devices.
We see some reluctance to use full TF-M distribution
e.g. Maybe will never use the attestation service
e.g. for Mbed TLS developer branch, may need to look into optimisations for small devices
Still want to use TF-M but some of PSA requirements may not be included.
Some vendors are saying TF-M is too big.
e.g. For PSA trusted storage using external storage, need rollback protection. But this is cumbersome for some customers. For our real implementation, we use internal storage.
We hope this kind of suggestion doesn't change governance for generic users of TF-M.
May end up not being fully certified.
Expect this to be internal build details.
Eric: We're seeing more of the same thing
Eric: Would you propose some simplified profile?
Frank: In Zephyr scope, we're already disabling features we don't need.
Frank: Turning off attestation is one basic thing but if we do, it is against PSA certification.
Frank: Seems OK for some devices, e.g. simple Bluetooth devices
(ran out of time)
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi
My apologies for the lateness but here are the minutes for December's TSC meeting...
Dan.
Present:
* Ahmad El Jouaid (ST)
* Eric Finco (ST)
* Praneeth Bajjuri (TI)
* Andrew Davis (TI)
* Antonio De Angelis (Arm)
* Anton Komlev (Arm)
* Bharath Subramanian (Arm)
* Matteo Carlini (Arm)
* Frank Kvamtrø (Nordic)
* Dominik Ermel (Nordic)
* Chris Palmer (Google)
* Julius Werner (Google)
* Moritz Fisher (Google)
Agenda:
* TI welcome
* Continue board discussion on impacts of regulation like CRA. Eric
* TF-M binary uploads (Ahmad)
Dan welcomes TI to TF.org TSC
Praneeth:
Andrew and Kamlash will be TI TSC reps
I will be on the board
We were part of TF earlier, 4-5 years back.
Want to be more engaged again.
Especially interested in OpenCI, TF-A and TF-M
We will talk about topics of interest in future calls.
We're also interested in UBoot, e.g. LTS strategy
We're engaged with UBoot maintainers.
Kamlesh working for 3 years at TI: security and power management
Linux crypto driver, TF-A, U-boot, ...
Will be handling any new development here
Dan: FW-handoff could be one other possible topic of interest. We're working with Simon Glass (UBoot maintainer) on this.
(https://github.com/FirmwareHandoff/firmware_handoff)
Continue board discussion on impacts of regulation like CRA
Eric:
There was a 2 day workshop by Linux Foundation in Amsterdam, 10-11 Dec
Impact of regulation
2 sets of rules in CRA specification: 1 for manufacturers, 1 for open source stewards
For manufacturers, it's reasonably clear. Have to comply with all requirements in CRA
For stewards, it's much more fuzzy:
* Specific to open source
* Responsible for maintaining security standards
ST understanding is there will be 3 workgroups setup to dive into this and influence the EU's finalisation of the spec.
There's also discussion under Global Platform (GP) on the same topic. ST is part of this and monitoring/contributing.
Most likely will have an impact on TF.org.
Agreement at board is to have regular conversations about this.
I think this is something we have to do. They're expecting some deployment as early as 2025.
Don: What's our likely investment here?
Eric: Keep contributing to stewards's role. May need more community management.
Eric: May need more CI. Too early to say
Frank: Does the GlobalPlatform work you mention also include and/or focus on SESIP?
Frank: Or is our focus more broad and generic?
Eric: Don't have an answer right now. Can check with our guy working with GP.
Frank: in Zephyr security committee, there's an ongoing requirement to handle requirements like these (also for US, Asian markets).
Frank: Unfortunately likely to be many levels removed from the workshop scope. So anything we learn there will be very valuable.
Frank: Thanks to ST for covering this.
Binary hosting topic (Ahmad):
Presented slides
Eric: We will send declassified version of the slides
Will be using our own boot stage (BL2 equivalent) so will only be publishing TF-M secure/ns apps
Export control problems with hosting own boot binary
Would like TF-M binary to be hosted with TF-M repo for ease of integration
Dan: Would it have a different license?
Eric: No
Dan/Julius: Can't we just use the tf-binaries repo?
(https://git.trustedfirmware.org/plugins/gitiles/tf-binaries/+/refs/heads/ma…)
Eric: Requirements are slightly different.
Would like to keep with platform port in TF-M source code
Dan: How to link precise source code version with the binary?
Eric: Maybe could sign binary with SHA-1.
Could have several versions in the repo.
Antonio: Is this for just new platforms or existing platforms too.
Eric: Just new platforms.
Anton: Concerned about side-effect of repo growth.
Anton: Why not host separately and keep link to TF-M source code?
Eric: Haven't discussed repo growth
Eric: Can we limit to release versions?
Ahmad: Yes, can do that and update with each release
Dan: Repo growth is not a blocker issues on its own. Can use tech like Git LFS (https://git-lfs.com/).
Frank: Could tf-binaries be a staging area for this?
Frank: Agree that releasing binaries is a good use-case
Frank: Could ST look into that?
Anton: I accept the use-case but also would prefer to use tf-binaries.
Eric: Next steps. Should we post something on TF-M forum
Anton: Happy to discuss in TF-M tech forum.
Frank: It might also be useful to store other artefacts to that separate repo.
Frank: We also do not use TF-M BL2. We have our own version. But it's still part of certification scope
AOB:
Call for ideas to use tf.org surplus
TF-M code size:
Frank: Nordic also cater for small devices.
We see some reluctance to use full TF-M distribution
e.g. Maybe will never use the attestation service
e.g. for Mbed TLS developer branch, may need to look into optimisations for small devices
Still want to use TF-M but some of PSA requirements may not be included.
Some vendors are saying TF-M is too big.
e.g. For PSA trusted storage using external storage, need rollback protection. But this is cumbersome for some customers. For our real implementation, we use internal storage.
We hope this kind of suggestion doesn't change governance for generic users of TF-M.
May end up not being fully certified.
Expect this to be internal build details.
Eric: We're seeing more of the same thing
Eric: Would you propose some simplified profile?
Frank: In Zephyr scope, we're already disabling features we don't need.
Frank: Turning off attestation is one basic thing but if we do, it is against PSA certification.
Frank: Seems OK for some devices, e.g. simple Bluetooth devices
(ran out of time)
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.
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.
Present:
Shebu Varghese Kuriakose (Arm)
Dan Handley (Arm)
Dave Rodgman (Arm)
Antonio De Angelis (Arm)
Frank Audun (Nordic)
PJ Bringer (ProvenRun)
Janos Follath (Arm)
Andrej Butok (NXP)
Joanna Farley (Arm)
David Brown (Linaro)
Julius Werner (Google)
Ruchika Gupta (NXP)
Michael Thomas (Renesas)
Dominik Ermel (Nordic)
Moritz Fischer (Google)
Eric Finco (ST)
Shebu gave Mbed TLS roadmap update (attached):
* Thread safety on PSA Crypto
* Allow building without software crypto implementation
* Enable TLS 1.3 by default
* Arm v8-A crypto extension support
Shebu: Want to align PSA Crypto headers in TF-M and Mbed TLS in the next TLS of both projects
Shebu: Would like feedback on the PSA Crypto thread safety when teams start to use it
Frank: Regarding schedule, we want to align with Zephyr LTS. Can we get Mbed TLS and TF-M LTS into Zephyr LTS?
Frank: Will propose to Zephyr security committee that Zephyr takes Mbed TLS 3.6 anyway even though it's not quite ready
Shebu: Understand that there were issues in the past when Zephyr took a non-LTS Mbed TLS
Shebu: Definitely happy to line up the ducks here
Shebu: Hopefully when we do TF-M LTS in April there will be enough buffer to get this into Zephyr LTS
Shebu: There will be a change in the Mbed TLS LTS cadence so both Mbed TLS and TF-M LTS cadence will be every 18 months.
Frank: Need some out of tree patches to enable certain TLS/DTLS use-cases using PSA Crypto API
Shebu: Think we're in a better place than we were with Mbed TLS 3.1/3.2
Shebu: After 3.6 LTS is out, it implies all new features will be on the 4.0 codeline
Shebu: Need to do a lot of planning before we can give dates for this
Shebu: 4.0 will make PSA Crypto the default main crypto API.
DaveR: I think we're agreed we want to remove (not deprecate) the legacy cipher interfaces
DaveR: A lot of config options for legacy interface will be removed (PSA_WANT_* will be the default way of configuring)
Shebu: Please check for notifications in the mailing list about interface deprecation proposals
Ruchika: With respect to PSA Crypto repo separation, will people be able to integrate Mbed TLS with their own PSA Crypto implementation?
Janos: Probably not a goal of 4.0 but eventually would like to make that possible.
Janos: 4.0 is already quite ambitious so that is probably not realistic
Ruchika: Trying to enforce the removal of usage of the legacy interfaces, so wanted to confirm that's the plan
DaveR: Yes, that's the plan
Shebu: If anyone is able to help contribute to 4.0, that will help get it out the door earlier
Shebu: I know Ruchika was asking about benchmarking support but that's currently a future item in the roadmap
Frank: Don't see any PQC on this roadmap.
Frank: There is one implementation but not a standardised PSA Cypto API. Will it be moved?
Shebu: The algorithm in question (LMS) was implemented to unblock Arm's Runtime Security Engine (RSE) team but other algorithms are not on the roadmap yet.
Frank: Will there be a PSA Crypto API 1.3 to fix issues in the PSA API GitHub?
Shebu: I'm sure eventually there will be a PSA Crypto API 1.3. We'll add this to the roadmap.
AOB:
Dan: Don finally removed support for Phabricator (developer.trustedfirmware.org) and put it in an archive.
Dan: There are still a few references to this being fixed in the project documentation and website.
Dan: When complete, individual projects should notify their respective MLs.
Dan: We added security.txt file to the website. It's the standard approach to providing security information for issue reporting.
https://www.trustedfirmware.org/.well-known/security.txt
Dan: cgit is being deprecated too. https://git.trustedfirmware.org/ will soon point to gitiles (the in-built Gerrit web interface) instead.
Dan: git commands should continue to work as before.
Dan: Redirects will be in place for high level links to projects/files.
Dan: More specific links to versions/branches may get broken.
Dan: We're doing this to enable support for private branches/repos in Gerrit. Cgit bypasses Gerrit access permissions.
Frank: We were part of defining the ADAC spec. Before it was moved to TF.org ownership.
Frank: It currently seems a bit disconnected from TF-M. It still uses legacy Mbed TLS APIs.
Frank: Any plans to fix this? We're willing to help.
Frank: Would like this to be an officially supported feature.
Shebu: It's not abandoned. People are still working on it.
Shebu: It moved to tf.org to become a reference implementation.
Shebu: We put it in a separate repo as we thought other projects might be able to use it
Shebu: Currently only has MUSCA platforms support
Shebu: We want to enable using this at runtime not just boot time
Shebu: Agree we need to move to using PSA Crypto API. Think there also some usage of other non-MBed TLS Crypto API
Dan: Is this on the roadmap?
Shebu: ADAC runtime support is on the roadmap. We will have to look into legacy API deprecation.
Shebu: Think we're looking for co-maintainers for this. Only a couple of Arm people are on it.
Frank: We can put forward a couple of candidates
Frank: Visibility within TF-M project is what we'd like. We want to make this generically usable.
Frank: Certificate management testing scripts are still internal to the authors of the spec. It might make sense for TF.org to own them publicly, although they might give the wrong impression
Frank: We can take the details offline but we're happy that ADAC is still being developed
Shebu: Linaro connect is approaching. We have a couple of session submissions around TF.org
Hi all,
This is the agenda we have for tomorrow's TSC meeting:
*
mbed TLS roadmap update (@Shebu)
*
AOB
Please let me know if you have any specific topic you would like to add or have it discussed.
Thanks, Antonio
Dear all,
this is a reminder to call for an agenda for the upcoming TSC meeting. The Mbed TLS roadmap update originally planned has been postponed to the March TSC, so at the moment the agenda is empty. If you have anything to discuss please let me know by Tomorrow (14th) COB.
Thanks, Antonio
Hi all
Below are the minutes for last week's meeting (thanks to Antonio).
Regards
Dan.
=====
Shebu Varghese Kuriakose (Arm)
Dan Handley (Arm)
Antonio De Angelis (Arm)
Joanna Farley (Arm)
Pierre-Julien Bringer (ProvenRun)
Camille Greusard (ProvenRun)
Julius Werner (Google)
Moritz Fischer (Google)
Jidong Sun (Google)
KangKang Shen (FutureWei)
Eric Finco (ST)
Frank Audun (Nordic)
Andrej Butok (NXP)
Silvano Di Ninno (NXP)
David Brown (Linaro)
Dan: Welcome to Jidong (new Google rep, replacing Okash) and new members ProvenRun (Pierre-Julien and Camille)
Dan: Starting a new round of roadmap updates, starting with TF-M
Shebu presented TF-M roadmap (attached)
Shebu: Achievements of tf-m 2.0.0:
* Reduction in size for ECDSA using P256M
* Usage of split-build
* New mailbox non-secure agent api
* Non-secure interrupt latency for isolation level > 1
Shebu: Introduction and planning for LTS
* Previous plan was do first LTS in Jan. New plan is April
Shebu: Work continues on Hybrid Platforms
Shebu: TLS connection use case
* Realigning the full headers mainly
Shebu: Impact of LTS on PSA Certified.
* LTS released every 18 months and supported for 36 months. Bug fixes and security fixes backported.
* This will be delta evaluations for the PSA labs, and this will allow partners to keep certification on that branch
Shebu: Platform ports will be allowed on this LTS Branch when those happen
Eric: Sounds good. Will Mbed TLS will move to a similar cadence?
Shebu: Yes. Mbed TLS has had LTS for a long time, but now it's moving to 3 year support, which aligns with TF-M.
Shebu: Will have a new one every 18months (lifetime 3 years).
Dan: Also welcome to Frank, the new rep from Nordic...
Frank: Is there a lead time on the PSA labs to allow such cadence?
Shebu: Important consideration. If there's an external vulnerability, we might not be in control of public disclosure.
Shebu: TF.org security incident process will follow its own process. TF-M will push out it's fix as soon as it can. Trusted Stakeholders will get the fix under embargo.
Shebu: Not necessarily aligned with Trusted Lab release schedule.
Shebu: We have been clear with PSA certified program, but currently there is no guarantee on time needed for the new release to be validated before the vulnerability goes public.
Frank: I'm less concerned about security handling. More that companies might ask the same service from the same company at the same time.
Shebu: TrustCB have been very engaged with the process. You're right this is a concern.
Shebu: But it's not a separate process that everybody has to do when there's a new release. All can benefit from the same handling.
Shebu: PSA labs can share reports generated by other labs so easing the pressure around recertification for platforms
Shebu: If it's a generic fix, it will get applied to all platforms.
Frank: Good, there's some sharing of effort.
Shebu: In next release can move from RSA to ECDSA
* Blocked on moving to this lightweight PSA crypto layer.
Antonio: Looks like it will be in TF-M 2.1
Shebu: Are we expecting some mem size reduction?
Antonio: At least the same size or lower.
Eric: Will Cryptocell refactoring be done without breaking compatibility?
Shebu: Yes, we already moved to PSA Crypto interface before so this is just changing things underneath
Shebu: Enabling TF-M on RSE (formally known as RSS) is not shown on the roadmap
* RSE is firmware for a complete secure enclave. RSE has been presented in one of the previous TF-M tech forums
ProvenRun introduction (Camille):
* We're a French company providing security services. e.g. for Defence, IoT, ...
* Providers of secure operating systems for Cortex-M.
* Currently we integrate TF-M partitions from the upstream repository. This solution is currently delivered to STM (using our own SPM + TF-M partitions).
* Compatibility with official TF-M is important
* We're interested in technical subjects and future developments. Happy with the TF-M presentation contents just showed
* Interested in TF-M community and being a contributor in future.
* Do not hesitate to get in touch. Either Camille or Pierre-Julien will attend this TSC
Shebu: On the A profile, is that a trusted execution environment or a trusted operating system?
Camille: Just M-profile, it was a misunderstanding earlier.
Frank also briefly introduced Nordic/himself:
Frank: Nordic started on tiny ASICs. Now have more and more complex devices.
* Interested in MbedTLS, MCUBoot, TF-M, Zephyr
* Managed to get optimised signature verification working in products
* Very open source oriented.
Dan: Silvano is also new to the TSC
Silvano: Just filling in for Ruchika this time.
Dan gave a Phabricator migration update (Dan)
* Migration going well.
* Just TF-A and Mbed TLS project pages remaining.
* Created https://github.com/TrustedFirmware/tf_docs rendered in readthedocs for generic content like the Security Center.
* Hope to complete before end of Q1 so we can retire Phabricator (https://developer.trustedfirmware.org/)
Dear all,
we have just realized that there has been an issue with the meeting invite series for the TSC meeting. There should have been a TSC meeting today but it got cancelled by mistake. We are looking to reschedule it for next week (25th January 2024), and then we will re-instate the normal meeting series from February onwards. Will send meeting invites again later today.
Apologies for the inconvenience and for the short notice.
Thanks,
Antonio
