Hi, Please find the minutes/actions from last Thursday's TrustedFirmware TSC. Best regards Don - Sent on behalf to the Trustedfirmware TSC Chairs

Attendees

Dave Cocca, Joakim Bech, Anton Komlev Anton.Komlev@arm.com, Eric Finco, Julius Werner

Kevin Townsend, David Brown, Kangkang Shen, Abhishek Pandit

Lionel Debieve, Andrej Butok, Dan Handley, Andrej Butok, Don Harbin

Actions:

-

Dave Cocca develop an initial proposal on how to handle Security Patches midstream. Send to Joakim and Dan Handley for review, then to the TSC. -

Abhishek Pandit - ask PSA team how they handle security patches and provide feedback to TSC.

Minutes:

-

AP: Reminder - TS presentation next month -

JB: Timeline/Roadmaps for TS can be asked about next month -

DC: Security Patches - a policy in place for how patches rolled out, versions, how many versions to backport, etc. In particular, coming out with a new MCUrelease, want to align TF-M and mBedTLS -

AP: Some discussions happening. TF-M specific? -

DC: mBedTLS and TF-M -

AP: TF-M, Anton is Tech Lead. -

DanH: mbedTLS - relatively mature product going well and widely used. A history of LTS branches, etc. So there is a policy in place. All security and non-security bugs support is on the LTS branches. When released, fixes are part of the released version. All fixes updated at the same time. TF-M policy is relatively new, and it needs discussion on how to move this forward with consideration of costs. -

DC: Yes cost is a factor, and members doing it as well for their own s/w. The solution needs to be practical -

DanH: Reasonable to come up w/ policy related to security fixes. For example, have no release without all security fixes in place and validated. -

AP: Current releases are on a 3-4 month cadence, assuming that’s OK -

AK: TF-M has only a couple of incidents. Have hotfixes. The main issues is validation and test. Can’t expect an ad-hoc release. Should release on tested platforms. Can define the process and verification window. -

AP: Talking about a next release, not LTS -

AK: Correct -

DanH: We need to understand what all members want to see -

DC: With TF-M v1.2, we could put out a 1.2.1 for a Security Vulnerability with limited testing and validation of the patches. Customers must then decide if they want to integrate. Could be a 1.2.z, i.e. a revision versus version. Not officially tested standalone, but the patch would be available. -

AP: The question is if 1.1 is there, then what? -

DC: In how we do it, the 1.0 needs maintained, if prior, then have to go back further. Then if someone wants it fixed, must go to the next minor release -

DanH: So most recent release as a starting point? -

DC: yes -

AP: If TF-M makes a 1.2.1 release, for example, and it’s not being validated, what is the value? -

DC: from TF.org standpoint, patch release with limited testing. -

AK: Patch is available -

DanH: Is there a concern on backporting? -

DB: Conflict issue is more obvious. But testing is more important -

DonH: Why not run the full Open CI test suite? -

DB: That’s run on the branch, but not for separate vendor releases -

AP: So full release gets tested, then it’s up to vendors to pull into their own builds/boards. -

DanH: So running Open CI is enough? -

DC: Yes, that should be enough. Vendors can also do extra testing but can inform that it also ran on Open CI. As long as transparent. -

AP: Lack of experience on TF-M users and lack of definition of major and minor releases are clear. -

AK: Have a versioning schema. -

JB: Example - https://semver.org/ -

KKS: Older security patches often have a short time, so only as a reference is the level of commitment that can be made. -

DC: Agree wouldn’t release major versions until fully tested, but for ones not fully tested, could do the ad-hoc release. -

AP: In most cases, security patches are a reference. -

DanH: What Dave asked for doesn’t seem that costly. -

AK: The main difference is the amount of testing. -

AP: That proposal can go out. -

ACTION: ^^^ DC come up with the initial draft. Send to Joakim, Dan. -

DanH: Do these impact release schedules? -

JB: No. -

DC: If someone wants PSA level 2 certification, would they be able to use the current version (1.2 for example) with identified security patches? -

DanH: Not sure how this is handled. Need to ask PSA Team -

ACTION ^^^ AP -

Joakim: OP TEE content. Like to redirect OPTEE.org -

JB: Docs in multiple places and attempting to pull this together like the OP TEE readthedocs. -

JB: Where do we put Security Advisories. -

DanH: Why not in all documentation? -

DanH: Github has a way to list as well -

DB: Github solution is being used elsewhere - then code users automatically see the advisories. -

DB: Must have admin rights on the advisory repo. Can add people to do other tasks. -

JB: Can’t see a way to remove ones -

DB: Shared example for Zephyr. Data matches CVEs well. -

JB: The link to PR is nice. -

DB: No API yet but can get an alert. Must web scrape to get it. -

DanH: Avoiding Phabricator seems good -

JB: Agreed -

DanH: Github seems a good idea -

JB: Will plan to redirect. -

ArmV9 -

DanH: Armv9 announced, presented at a high level. CCA and realm mgt extensions included. The expectation is to have more details coming over the following months. May see some TF-A EL3 code support patches but won’t change how things work. Later, some changes could be more invasive. -

JB: Memory Tagging extension has been around, why mentioned here? -

DanH: Not sure, a stepping stone to Morello? Not sure if anything additional in V9. -

AP: Note this is just the first announcement. Must wait on some details. -

DanH: Expect more technical presentations in the upcoming months