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)
