Attendees
Dave Cocca, Joakim Bech, Anton Komlev, 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