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.
