Subject: [TF-TSC] TSC minutes 2024-12-19
From: Dan Handley via TSC <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 13 Jan 2025 15:26:20 +0000
List-Id: Trusted Firmware TSC <tsc.lists.trustedfirmware.org>

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/master/readme.rst)

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)