Hi all
I only have a few small topics for today's TSC so I'm not expecting a long meeting (yes, I know I've said that before). Please let me know if you have anything else.
*
PSA Certified API spec governance.
*
TF.org CVE allocation
*
CoreCollective CCA working group
Regards
Dan.
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
