Dears,
apologies for the short notice, but having no agenda for today and no planned roadmap update as well, I propose to cancel the meeting also in view of a lighter expected attendance due to to Easter holiday period.
Apologies again for the short notice,
Thanks,
Antonio
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.
Hi all
So far I have the following agenda for the TSC meeting tomorrow:
* Discussion on the use of AI assistants (continued from the board meeting).
* Continued discussion on TF-M code size and impact on PSA certification (this was cut short in the December meeting).
Let me know if you want to discuss anything else.
Regards
Dan.
FYI in case you didn’t receive the earlier cancellation. Today’s TSC meeting is cancelled.
Regards
Dan.
-----Original Appointment-----
From: Karen Power via Tsc-private <tsc-private(a)lists.trustedfirmware.org<mailto:tsc-private@lists.trustedfirmware.org>> On Behalf Of Karen Power
Sent: Wednesday, January 15, 2025 2:18 PM
To: Karen Power; Dan Handley; Eric Finco (eric.finco(a)st.com<mailto:eric.finco@st.com>); lionel.debieve(a)st.com<mailto:lionel.debieve@st.com>; kangkang.shen(a)gmail.com<mailto:kangkang.shen@gmail.com>; Antonio De Angelis; Don Harbin; jwerner(a)google.com<mailto:jwerner@google.com>; David Brown (david.brown(a)linaro.org<mailto:david.brown@linaro.org>); davidb(a)quicinc.com<mailto:davidb@quicinc.com>; kangkang.shen(a)futurewei.com<mailto:kangkang.shen@futurewei.com>; frank.kvamtro(a)nordicsemi.no<mailto:frank.kvamtro@nordicsemi.no>; bpeckham(a)google.com<mailto:bpeckham@google.com>; brandon.hussey(a)renesas.com<mailto:brandon.hussey@renesas.com>; moritzf(a)google.com<mailto:moritzf@google.com>; palmer(a)google.com<mailto:palmer@google.com>; afd(a)ti.com<mailto:afd@ti.com>; praneeth(a)ti.com<mailto:praneeth@ti.com>; Ruchika Gupta; Camille Greusard; pierre-julien.bringer(a)provenrun.com<mailto:pierre-julien.bringer@provenrun.com>; dominik.ermel(a)nordicsemi.no<mailto:dominik.ermel@nordicsemi.no>; Andrej Butok; tsc-private(a)lists.trustedfirmware.org<mailto:tsc-private@lists.trustedfirmware.org>; Michael Thomas; kamlesh(a)ti.com<mailto:kamlesh@ti.com>
Cc: Shebu Varghese Kuriakose; Joanna Farley; Matteo Carlini
Subject: [Tsc-private] Cancelled event with note: TrustedFirmware TSC @ Thu 16 Jan 2025 12pm - 12:55pm (EST) (tsc-private(a)lists.trustedfirmware.org<mailto:tsc-private@lists.trustedfirmware.org>)
When: 16 January 2025 09:00-09:55 America/Los_Angeles.
Where: zoom see below
TrustedFirmware TSC
This event has been cancelled with a note:
"Meeting cancelled as not enough time has passed since everyone returned from the holidays. "
Trusted Firmware is inviting you to a scheduled Zoom meeting.
Topic: TrustedFirmware TSC
Time: Feb 15, 2024 05:00 PM London
Every month on the Third Thu, 20 occurrence(s)
Feb 15, 2024 05:00 PM
Mar 21, 2024 05:00 PM
Apr 18, 2024 05:00 PM
May 16, 2024 05:00 PM
Jun 20, 2024 05:00 PM
Jul 18, 2024 05:00 PM
Aug 15, 2024 05:00 PM
Sep 19, 2024 05:00 PM
Oct 17, 2024 05:00 PM
Nov 21, 2024 05:00 PM
Dec 19, 2024 05:00 PM
Jan 16, 2025 05:00 PM
Feb 20, 2025 05:00 PM
Mar 20, 2025 05:00 PM
Apr 17, 2025 05:00 PM
May 15, 2025 05:00 PM
Jun 19, 2025 05:00 PM
Jul 17, 2025 05:00 PM
Aug 21, 2025 05:00 PM
Sep 18, 2025 05:00 PM
Please download and import the following iCalendar (.ics) files to your calendar system.
Monthly: https://linaro-org.zoom.us/meeting/tJYpdO6pqjwtE9ItoYR_-W2AvXKbkkhzuUvg/ics…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fmeeting%2Ft…>
Join Zoom Meeting
https://linaro-org.zoom.us/j/92437147796?pwd=NXd1a1U2eGlnZkNiUTB1T0xnYzB5Zz…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9243714…>
Meeting ID: 924 3714 7796
Passcode: 100152
---
One tap mobile
+16699009128,,92437147796# US (San Jose)
+17193594580,,92437147796# US
---
Dial by your location
• +1 669 900 9128 US (San Jose)
• +1 719 359 4580 US
• +1 253 205 0468 US
• +1 253 215 8782 US (Tacoma)
• +1 346 248 7799 US (Houston)
• +1 669 444 9171 US
• +1 564 217 2000 US
• +1 646 558 8656 US (New York)
• +1 646 931 3860 US
• +1 689 278 1000 US
• +1 301 715 8592 US (Washington DC)
• +1 305 224 1968 US
• +1 309 205 3325 US
• +1 312 626 6799 US (Chicago)
• +1 360 209 5623 US
• +1 386 347 5053 US
• +1 507 473 4847 US
• 833 548 0276 US Toll-free
• 833 548 0282 US Toll-free
• 833 928 4608 US Toll-free
• 833 928 4609 US Toll-free
• 833 928 4610 US Toll-free
• 877 853 5247 US Toll-free
• 888 788 0099 US Toll-free
Meeting ID: 924 3714 7796
Find your local number: https://linaro-org.zoom.us/u/abwnK0XVLY<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fu%2FabwnK0X…>
When
Thursday 16 Jan 2025 ⋅ 12pm – 12:55pm (Eastern Time - Toronto)
Location
zoom see below
View map<https://www.google.com/maps/search/zoom+see+below?hl=en-GB>
Guests
Karen Power<mailto:karen.power@linaro.org>- organiser
Don Harbin<mailto:don.harbin@linaro.org>- creator
dan.handley(a)arm.com<mailto:dan.handley@arm.com>
eric.finco(a)st.com<mailto:eric.finco@st.com>
lionel.debieve(a)st.com<mailto:lionel.debieve@st.com>
kangkang.shen(a)gmail.com<mailto:kangkang.shen@gmail.com>
antonio.deangelis(a)arm.com<mailto:antonio.deangelis@arm.com>
jwerner(a)google.com<mailto:jwerner@google.com>
David Brown<mailto:david.brown@linaro.org>
davidb(a)quicinc.com<mailto:davidb@quicinc.com>
kangkang.shen(a)futurewei.com<mailto:kangkang.shen@futurewei.com>
frank.kvamtro(a)nordicsemi.no<mailto:frank.kvamtro@nordicsemi.no>
bpeckham(a)google.com<mailto:bpeckham@google.com>
brandon.hussey(a)renesas.com<mailto:brandon.hussey@renesas.com>
moritzf(a)google.com<mailto:moritzf@google.com>
palmer(a)google.com<mailto:palmer@google.com>
afd(a)ti.com<mailto:afd@ti.com>
praneeth(a)ti.com<mailto:praneeth@ti.com>
Ruchika Gupta<mailto:ruchika.gupta_1@nxp.com>
Camille Greusard<mailto:camille.greusard@provenrun.com>
pierre-julien.bringer(a)provenrun.com<mailto:pierre-julien.bringer@provenrun.com>
dominik.ermel(a)nordicsemi.no<mailto:dominik.ermel@nordicsemi.no>
Andrej Butok<mailto:andrey.butok@nxp.com>
tsc-private(a)lists.trustedfirmware.org<mailto:tsc-private@lists.trustedfirmware.org>
Michael Thomas<mailto:michael.thomas@renesas.com>
kamlesh(a)ti.com<mailto:kamlesh@ti.com>
shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> - optional
joanna.farley(a)arm.com<mailto:joanna.farley@arm.com> - optional
matteo.carlini(a)arm.com<mailto:matteo.carlini@arm.com> - optional
Invitation from Google Calendar<https://calendar.google.com/calendar/>
You are receiving this email because you are an attendee of the event.
Forwarding this invitation could allow any recipient to send a response to the organiser, be added to the guest list, invite others regardless of their own invitation status or modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>
Dear TSC members,
Find attached the slides presented by Ahmad for ST regarding TF-M binary hosting during December TSC meeting.
Regards,
Eric Finco
[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: logo_big5]
Eric FINCO | Tel: +33 (0)2 4402 7500
MDG | Technical Specialist
From: Dan Handley <Dan.Handley(a)arm.com>
Sent: Monday, January 13, 2025 4:29 PM
To: Eric FINCO <eric.finco(a)st.com>; Ahmad EL JOUAID <ahmad.eljouaid(a)st.com>
Subject: RE: TSC minutes 2024-12-19
Hi Eric/Ahmad
I'd be grateful if you could send the (non-confidential version of the) slides you showed regarding binary hosting.
Regards
Dan.
From: Dan Handley via TSC <tsc(a)lists.trustedfirmware.org<mailto:tsc@lists.trustedfirmware.org>>
Sent: 13 January 2025 15:26
To: tsc(a)lists.trustedfirmware.org<mailto:tsc@lists.trustedfirmware.org>
Subject: [TF-TSC] TSC minutes 2024-12-19
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/ma…)
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)
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
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/ma…)
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)
Hi all
The next TSC meeting is this Thursday (Dec 19). Please let me know if you have any topics you'd like to discuss. Some potential ones are:
* TI welcome
* Continue board discussion on potential TF-funded activities,
* E.g. "Code Development using AI". KangKang - do you want to do this or should we push it to a future meeting?
* Continue board discussion on impacts of regulation like CRA. Eric - do you want to do this?
Also, we're getting close to the holiday season so please let me know if you're available, otherwise I may have to cancel.
Regards
Dan.
Present:
Ilias Apalodimas (Linaro)
Antonio De Angelis (Arm)
Dan Handley (Arm)
Matteo Carlini (Arm)
KangKang Shen (FutureWei)
Frank Audun (Nordic)
LionelD (ST)
Michael Thomas (Renesas)
Julius Werner (Google)
(Ilias speaking unless otherwise stated)
There have been some activities around stability and working with the latest kernel.
Some work to improve secure data path support. How to deal with encrypted buffers in secure world.
Each vendor has its own way of doing this. Want to provide a common way.
Jens picked this up and is working with kernel maintainers to provide the common solution.
It works with both FF-A and direct SMC APIs.
He'll be sending v3 kernel patches next week. This should be merged soon.
fTPM:
Microsoft previously had 2 repos to support OP-TEE TA fTPM; a ref TPM library and an OP-TEE TA.
The latter is no longer available, so Linaro are going to host this alongside the other OP-TEE repos.
OP-TEE secure storage was previously under control of the kernel. It relied on a userspace supplicant to mediate access to RPMB.
That was OK when we needed to access secure storage late in the bootflow.
But there's a problem if you needed this early in the kernel bootflow (before userspace is loaded).
We have moved a big portion of the supplicant code inside the kernel itself.
This works much better than previously.
Lionel: Is it a standalone subsystem that can be used e.g. in UBoot?
Uboot already has direct access to flash.
The problem was early kernel code that needed access before userspace was up
Jens also working on dynamic configuration of OP-TEE for e.g. number of cores, amount of secure memory.
We plan to work on FF-A 1.2. We want this in OP-TEE and Xen.
We think the memory sharing interfaces and other APIs will be useful.
Expect this to land soon.
We're also doing some hardening.
Increasing test coverage, CI improvements , enabling QEMU-sbsa
Secure Partition support:
There's an implicit dependency on thread support, which we're trying to remove
We're thinking about how to launch S-EL0 SPs without an entity in S-EL1 (like Hafnium)
Also support for Logical SPs, which is not supported at the moment
Lionel: Not sure if you're planning to use Device Tree (DT) for the dynamic configuration?
We're trying to base OP-TEE config on DT format
The problem is DT is OP-TEE specific and embedded within the OP-TEE image
Have you thought about adding support for the kernel DT?
Why do we want to pass that to OP-TEE?
Lionel: We already have a number of drivers in OP-TEE. Would be good to be able to discover them.
Lionel: Have already mentioned it to Jens
I haven't discussed this with Jens but it's an interesting idea
Don't think we have a function in OP-TEE to handle DT
Lionel: We have made use of the embedded DT in OP-TEE image but it's not ideal as this is specific to OP-TEE
Could be a security risk.
Lionel: This could use existing support in TF-A
Lionel: Can discuss offline
Suggest using FW handoff protocol, which includes support for DT entries
https://github.com/FirmwareHandoff/firmware_handoff
Would prefer a standard method than every vendor doing their own thing
Dan: Maybe some additional Transfer Entries (TEs) are needed for OP-TEE?
Dan: The preference is to define TEs with specific fields for firmware use rather than generic container formats like DT
Dan: Though using the kernel DT in firmware is fine.
