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.
