Page MenuHomePhabricator

TF-M Security Patch Release Process
Updated 125 Days AgoPublic

Version 1 of 12: You are viewing an older version of this document, as it appeared on May 20 2021, 5:52 PM.
Draft in review

This document outlines the proposal for backporting of TF-M security fixes to previous releases and the testing policy of such releases.

Last Author
abhishek-pandit
Last Edited
May 20 2021, 5:52 PM

Event Timeline

DaveCocca edited the content of this document. (Show Details)May 20 2021, 6:49 PM
DaveCocca edited the content of this document. (Show Details)
DaveCocca edited the content of this document. (Show Details)May 20 2021, 6:52 PM
DaveCocca edited the content of this document. (Show Details)
DaveCocca edited the content of this document. (Show Details)May 20 2021, 6:56 PM

Following the discussion on the meeting I would update my comment:

  1. ...
  2. Suggest providing a fix to the last release only. That means if the current release is v1.3.0 then fix will create v1.3.1 in a new branch.
Anton-TF edited the content of this document. (Show Details)Jul 7 2021, 5:18 PM
Anton-TF edited the content of this document. (Show Details)
abhishek-pandit edited the content of this document. (Show Details)Jul 15 2021, 3:34 PM
abhishek-pandit edited the content of this document. (Show Details)

Here's the original proposal:

Security Vulnerabilities will be fixed as quickly as possible after discovery.

The fix will result in a patch release where the latest major or minor version is updated per Semantic versioning. For example, if a bug is found in v3.1.0, the fix will result in a v3.1.1 patch release.
The fix will also be applied to any LTS branches. So for example, if there is a v2.0.0 LTS version, it will be upgrade to v2.0.1 with the patch.

All released patch versions will be fully regression tested including new test(s) to cover the vulnerability.

TrustedFirmware.org will not release vulnerability code fixes on their own. Fixes will only be released as a complete TF-M package.

Note: Separate but related to this proposal, TF-M needs to have a formalized LTS process and standard.

Here's the proposal with feedback, added inline and discussed in 5/20/21 TSC:

Security Vulnerabilities will be fixed as quickly as possible after discovery.
The fix will result in a patch release where the latest major or minor version is updated per Semantic versioning. For example, if a bug is found in v3.1.0, the fix will result in a v3.1.1 patch release.

Dan Handley: I think we should specifically say the latest vulnerable release. The latest release may already contain the fix (as was the case recently).
DH: Also, I would avoid the reference to semantic versioning since TF-M does not in general use semantic versioning for major/minor releases.
Dave Cocca: TF-M Release Cadence and Process mentions “Trusted Firmware-M uses a semantic versioning scheme.”

https://ci-builds.trustedfirmware.org/static-files/TZFdL484qZZgYcbWIGLS09zbtYWlsNtB4w34XlUj6OUxNjIxNTIzMzczMzM5Ojk6YW5vbnltb3VzOmpvYi90Zi1tLWJ1aWxkLWRvY3MtbmlnaHRseS9sYXN0U3RhYmxlQnVpbGQvYXJ0aWZhY3Q=/trusted-firmware-m/build/docs/user_guide/html/docs/releases/release_process.html#release-cadence-and-process

The fix will also be applied to any LTS branches. So for example, if there is a v2.0.0 LTS version, it will be upgrade to v2.0.1 with the patch.

Joakim Bech: As such I have no concerns patching LTS. I think we debated how far back in history we will patch LTS branches. Should we propose a number? If TF members could give a hint on how "old" versions they are using, then that might give us the answer? At least a starting point.
DH: I don't see that we need to say anything specific about how far back or how many versions number we patch. The LTS policy will specify a lifetime for each LTS branch and we should patch throughout that LTS's lifetime.

All released patch versions will be fully regression tested including new test(s) to cover the vulnerability.

JB: +1
DH: I think in the TSC meeting we said that regression testing would only cover normal CI testing, not all testing associated with making a release. Also, adding new test(s) to cover the vulnerability may not be practical if there is no known exploit or the granularity of the test framework is not sufficient. Perhaps just say "where possible"?
DC: Agree with “where possible”.
What’s the diff between “normal CI testing” and “testing assoc w/ making a release”? Normal CI testing seems OK at least as a starting point.

TrustedFirmware.org will not release vulnerability code fixes on their own. Fixes will only be released as a complete TF-M package.

JB: So instead of sending a set of separate *.patch files for the fixes, we should deliver either a branch or a tag in a Git (shared privately to the trusted stakeholders)? I think that should work. Individual patches are easy to send as attachments via email, but it can become a bit of a challenge to keep track of them when you start sending out fixes to the patches themselves (i.e., patch version > v1). In those cases it's probably easier to just hand out a branch or tag in a private tree.
DH: +1
JB: What options do we have when it comes to sharing branches and tags with stakeholders? I'm currently moving other all security advisories from op-tee.org to instead leverage the security incident reporting at GitHub (under the OP-TEE project). GitHub has the ability to invite people to collaborate and see patches in the works. In TF, all sub-projects have different ways of working with git-trees. So, I'd like to understand if we have the same possibilities for TF-M and others. Having said that, I don't think GitHub is a silverbullet solution either, since I don't believe their security incident feature is created as "security disclosure" with large groups. I think their take on this right now is more collaboration on mitigation fixes with a small group of developers.
DH: I agree that GitHub Security Advisories is not going to work for all projects. But using a known tag format should be applicable across projects.

Note: Separate but related to this proposal, TF-M needs to have a formalized LTS process and standard.

JB: Agree (and probably not only TF-M).

Anton Komlev Reply:
Please find below the view from TF-M perspective :

  1. The discussed ideas fits well to the project needs and goals: each fix will increment the hot fix number in TF-M version. (see TF-M Release Cadence and Process)
  2. Suggest to update the current and previous releases only. That means if the current release is v1.3.0: a. a new fix makes v1.3.1 and 1.2.x+1 b. releasing v1.4.0 deprecates v1.2.x. This makes TF-M LTSes 8 months life time.
  3. Ignore the past releases first time starting the process. (TF-M special case: missing patch in the previous release)
  4. Test scope: If a fix is a platform independent then regression suit on a default platform is enough: an521 at the moment.

end

abhishek-pandit published a new version of this document.Jul 15 2021, 3:35 PM
shebuk edited the content of this document. (Show Details)Jul 15 2021, 3:40 PM
michaelthomasj edited the content of this document. (Show Details)Aug 3 2021, 4:17 PM