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.
