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