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.
