Hi

My apologies for the lateness but here are the minutes for December's TSC meeting...

Dan.

Present:

* Ahmad El Jouaid (ST) * Eric Finco (ST) * Praneeth Bajjuri (TI) * Andrew Davis (TI) * Antonio De Angelis (Arm) * Anton Komlev (Arm) * Bharath Subramanian (Arm) * Matteo Carlini (Arm) * Frank Kvamtrø (Nordic) * Dominik Ermel (Nordic) * Chris Palmer (Google) * Julius Werner (Google) * Moritz Fisher (Google)

Agenda:

* TI welcome * Continue board discussion on impacts of regulation like CRA. Eric * TF-M binary uploads (Ahmad)

Dan welcomes TI to TF.org TSC Praneeth: Andrew and Kamlash will be TI TSC reps I will be on the board We were part of TF earlier, 4-5 years back. Want to be more engaged again. Especially interested in OpenCI, TF-A and TF-M We will talk about topics of interest in future calls. We're also interested in UBoot, e.g. LTS strategy We're engaged with UBoot maintainers. Kamlesh working for 3 years at TI: security and power management Linux crypto driver, TF-A, U-boot, ... Will be handling any new development here Dan: FW-handoff could be one other possible topic of interest. We're working with Simon Glass (UBoot maintainer) on this. (https://github.com/FirmwareHandoff/firmware_handoff)

Continue board discussion on impacts of regulation like CRA Eric: There was a 2 day workshop by Linux Foundation in Amsterdam, 10-11 Dec Impact of regulation 2 sets of rules in CRA specification: 1 for manufacturers, 1 for open source stewards For manufacturers, it's reasonably clear. Have to comply with all requirements in CRA For stewards, it's much more fuzzy:

* Specific to open source * Responsible for maintaining security standards ST understanding is there will be 3 workgroups setup to dive into this and influence the EU's finalisation of the spec. There's also discussion under Global Platform (GP) on the same topic. ST is part of this and monitoring/contributing. Most likely will have an impact on TF.org. Agreement at board is to have regular conversations about this. I think this is something we have to do. They're expecting some deployment as early as 2025.

Don: What's our likely investment here? Eric: Keep contributing to stewards's role. May need more community management. Eric: May need more CI. Too early to say Frank: Does the GlobalPlatform work you mention also include and/or focus on SESIP? Frank: Or is our focus more broad and generic? Eric: Don't have an answer right now. Can check with our guy working with GP. Frank: in Zephyr security committee, there's an ongoing requirement to handle requirements like these (also for US, Asian markets). Frank: Unfortunately likely to be many levels removed from the workshop scope. So anything we learn there will be very valuable. Frank: Thanks to ST for covering this.

Binary hosting topic (Ahmad): Presented slides Eric: We will send declassified version of the slides Will be using our own boot stage (BL2 equivalent) so will only be publishing TF-M secure/ns apps Export control problems with hosting own boot binary Would like TF-M binary to be hosted with TF-M repo for ease of integration Dan: Would it have a different license? Eric: No Dan/Julius: Can't we just use the tf-binaries repo? (https://git.trustedfirmware.org/plugins/gitiles/tf-binaries/+/refs/heads/mas...) Eric: Requirements are slightly different. Would like to keep with platform port in TF-M source code Dan: How to link precise source code version with the binary? Eric: Maybe could sign binary with SHA-1. Could have several versions in the repo. Antonio: Is this for just new platforms or existing platforms too. Eric: Just new platforms. Anton: Concerned about side-effect of repo growth. Anton: Why not host separately and keep link to TF-M source code? Eric: Haven't discussed repo growth Eric: Can we limit to release versions? Ahmad: Yes, can do that and update with each release Dan: Repo growth is not a blocker issues on its own. Can use tech like Git LFS (https://git-lfs.com/). Frank: Could tf-binaries be a staging area for this? Frank: Agree that releasing binaries is a good use-case Frank: Could ST look into that? Anton: I accept the use-case but also would prefer to use tf-binaries. Eric: Next steps. Should we post something on TF-M forum Anton: Happy to discuss in TF-M tech forum. Frank: It might also be useful to store other artefacts to that separate repo. Frank: We also do not use TF-M BL2. We have our own version. But it's still part of certification scope

AOB: Call for ideas to use tf.org surplus

TF-M code size: Frank: Nordic also cater for small devices. We see some reluctance to use full TF-M distribution e.g. Maybe will never use the attestation service e.g. for Mbed TLS developer branch, may need to look into optimisations for small devices Still want to use TF-M but some of PSA requirements may not be included. Some vendors are saying TF-M is too big. e.g. For PSA trusted storage using external storage, need rollback protection. But this is cumbersome for some customers. For our real implementation, we use internal storage. We hope this kind of suggestion doesn't change governance for generic users of TF-M. May end up not being fully certified. Expect this to be internal build details. Eric: We're seeing more of the same thing Eric: Would you propose some simplified profile? Frank: In Zephyr scope, we're already disabling features we don't need. Frank: Turning off attestation is one basic thing but if we do, it is against PSA certification. Frank: Seems OK for some devices, e.g. simple Bluetooth devices (ran out of time)