Attendees : - Abhishek Pandit, Arm - Andrej Butok, NXP - Anton Komlev, Arm - Dan Handley, Arm - David Brown, Linaro - Dave Cocca, Renesas - Eric Finco, ST - Gyorgy Szing, Arm - Joakim Bech, Linaro - Julius Werner, Google - Kangkang Shen, Futurewei - Kevin Oerton, NXM - Michael Thomas, Renesas - Shebu Varghese Kuriakose, Arm - Lionel Debieve, ST
(Thanks Joakim for taking the notes!)
Trusted Services & PSA - Shebu presented Trusted Services roadmap (to be circulated). - Crypto, Attestation and secure storage is the three first main API's. - TF-M available on several platforms. - General ask to extend PSA to Cortex-A devices, Edge devices etc. More complicated environment, since many different stacks etc. This was the reason why Trusted Services was born. - Initial code base etc for Trusted Services can be found at TF.org. - T.S. is a framework to develop security related services. - Communication can be FF-A or OpenAMP. - Started to implement same services on Cortex-A as we've done for the TF-M. - Michael: Is this expected to reach TF-M? Shebu: No, it's only for TF-A. - Andrej: Will interface be the same as in TF-M? Shebu: Yes - FF-A is the protocol between all exception levels (pre-Armv8.4 devices where there are no S-EL2). Right now development takes place on Arm models (FVP). - For Armv8.4 we also have Secure EL-2 (Hafnium). I.e., the secure partition manager (SPM) is in S-EL2. - Kevin: TA's access? pre8.4 only to non-secure side? Shebu: Traditional TA's will co-exist with SP's (via a shim layer). - TS: 2021/Q2: Attest SP, Protected Storage SP, FF-A direct messaging, FIP based booting. - TS: 2021/Q3: Attest SP continues, StMM Updates, PSA Functional API testing, 32bit support SEL0/SP, Storage backend intergration. - TS: 2021/Q4: 32-bit support SEL0/SP continues, Platform Security Firmware Update for A-profile, Meta-arm yocto support. - OP-TEE Q2,3,4: Co-developed (pending changes can be found in a TF.org branch). - OP-TEE users will get all changes from the official upstream project, and TS services from TF.org. - Kangkang: Multicore, how to switch to secure side. Gyorgy: Same as OP-TEE. JB: Everything on secure side runs on a single core. I.e., a TA cannot use two or more cores. Kangkang: On x86, it's possible to switch so you utilize all cores.
Patch management - security issues - LTS - Dave: Generally positive feedback. - Dave: Dan wanted to avoid the semantic versioning? What's the background for the concern? We'd like to use the Major, Minor, Fix Anton: TF-M uses semver, but it's tweaked for it's own purposes. David B: Do we have any reason not to compel with the standard? Anton: No hotfix? Michael: Yes it's there, they call it patch. https://semver.org/ Anton: Wanted to use the "Patch" for security fixes only. Abhishek: On high-level it matches, but not backwards-compatible for "patch". Hence strictly not Semantic Versioning. - Dave: We should reference the link in the release cadence and process. - Dave: Dan, LTS policy, use the lifetime of the branch. Anton proposed a 8 month coverage (two releases back basically). TF-M have stayed away from the LTS terminology. Abhishek: Should we patch all old release or only the last one? The last is properly tested, but the one prior to that will not have the same amount of testing. Dave: Customers must be comfortable with understanding for how long the LTS will be there and will be patched. Need to figure out how far back we will test old release when doing security fixes. Shebu: Not trivial from a resourcing point of view. Three years should be more than enough, more than that will probably not make sense, since things will likely have been re-designed. Michael: TF-M is in an early state, maybe pre-mature to define LTS. But once customer started to deploy it, we must assure that there are patches/stable builds maintained and security holes and bugs fixed. Shebu: Everyone in the board supports the LTS, the question is to frame it (time). Dave: For now leave LTS out and mention the previous version as starting point. Abhishek: Sounds OK. Companies on older version will to thorough testing since they have products out already. Dave: Major, minor? Abhishek: Yes, only use Major and Minor. - Dave: testing, on the minor release that gets the hot-fix, what is the amount of testing? Need clarification. Anton: Normal CI testing is overnight, sanity tests, performance etc. All done on FVP. For release test, we ask "everyone" to test on their boards and we give the 2 week window for the testing. Dave: Once we have OpenCI in place, things could improve for hot-fix testing? Anton: Yes, that's our optimistic view on it. Abhishek: Automatic successful testing is not the problem. It's the failing that is the challenge. Board/device owner will have to help with investigations. Michael: Also important to add new test, testing the security fix. Will the test suite also be updated for old versions. Anton: If we provide a fix, do we want to keep the branch forever? Dave: How to get it to Phabricator? Abhishek: You can add it there yourself. Will help you with permissions etc.
Feedback from TSC reps - Abhishek: Looking for more feedback for the next meeting. - Joakim: Reminder that the email tsc@... is going to a public list seen by anyone https://lists.trustedfirmware.org/pipermail/tsc/. Abhishek: Will see if I'll create an internal Phabricator page.
Hi All,
The Trusted Services presentation attached
Regards, Shebu
From: Abhishek Pandit Abhishek.Pandit@arm.com Sent: Wednesday, May 26, 2021 9:20 AM To: tsc@lists.trustedfirmware.org Cc: Shebu Varghese Kuriakose Shebu.VargheseKuriakose@arm.com; Gyorgy Szing Gyorgy.Szing@arm.com; Anton Komlev Anton.Komlev@arm.com Subject: TSC Minutes 20 May 2021
Attendees : - Abhishek Pandit, Arm - Andrej Butok, NXP - Anton Komlev, Arm - Dan Handley, Arm - David Brown, Linaro - Dave Cocca, Renesas - Eric Finco, ST - Gyorgy Szing, Arm - Joakim Bech, Linaro - Julius Werner, Google - Kangkang Shen, Futurewei - Kevin Oerton, NXM - Michael Thomas, Renesas - Shebu Varghese Kuriakose, Arm - Lionel Debieve, ST
(Thanks Joakim for taking the notes!)
Trusted Services & PSA - Shebu presented Trusted Services roadmap (to be circulated). - Crypto, Attestation and secure storage is the three first main API's. - TF-M available on several platforms. - General ask to extend PSA to Cortex-A devices, Edge devices etc. More complicated environment, since many different stacks etc. This was the reason why Trusted Services was born. - Initial code base etc for Trusted Services can be found at TF.org. - T.S. is a framework to develop security related services. - Communication can be FF-A or OpenAMP. - Started to implement same services on Cortex-A as we've done for the TF-M. - Michael: Is this expected to reach TF-M? Shebu: No, it's only for TF-A. - Andrej: Will interface be the same as in TF-M? Shebu: Yes - FF-A is the protocol between all exception levels (pre-Armv8.4 devices where there are no S-EL2). Right now development takes place on Arm models (FVP). - For Armv8.4 we also have Secure EL-2 (Hafnium). I.e., the secure partition manager (SPM) is in S-EL2. - Kevin: TA's access? pre8.4 only to non-secure side? Shebu: Traditional TA's will co-exist with SP's (via a shim layer). - TS: 2021/Q2: Attest SP, Protected Storage SP, FF-A direct messaging, FIP based booting. - TS: 2021/Q3: Attest SP continues, StMM Updates, PSA Functional API testing, 32bit support SEL0/SP, Storage backend intergration. - TS: 2021/Q4: 32-bit support SEL0/SP continues, Platform Security Firmware Update for A-profile, Meta-arm yocto support. - OP-TEE Q2,3,4: Co-developed (pending changes can be found in a TF.org branch). - OP-TEE users will get all changes from the official upstream project, and TS services from TF.org. - Kangkang: Multicore, how to switch to secure side. Gyorgy: Same as OP-TEE. JB: Everything on secure side runs on a single core. I.e., a TA cannot use two or more cores. Kangkang: On x86, it's possible to switch so you utilize all cores.
Patch management - security issues - LTS - Dave: Generally positive feedback. - Dave: Dan wanted to avoid the semantic versioning? What's the background for the concern? We'd like to use the Major, Minor, Fix Anton: TF-M uses semver, but it's tweaked for it's own purposes. David B: Do we have any reason not to compel with the standard? Anton: No hotfix? Michael: Yes it's there, they call it patch. https://semver.org/ Anton: Wanted to use the "Patch" for security fixes only. Abhishek: On high-level it matches, but not backwards-compatible for "patch". Hence strictly not Semantic Versioning. - Dave: We should reference the link in the release cadence and process. - Dave: Dan, LTS policy, use the lifetime of the branch. Anton proposed a 8 month coverage (two releases back basically). TF-M have stayed away from the LTS terminology. Abhishek: Should we patch all old release or only the last one? The last is properly tested, but the one prior to that will not have the same amount of testing. Dave: Customers must be comfortable with understanding for how long the LTS will be there and will be patched. Need to figure out how far back we will test old release when doing security fixes. Shebu: Not trivial from a resourcing point of view. Three years should be more than enough, more than that will probably not make sense, since things will likely have been re-designed. Michael: TF-M is in an early state, maybe pre-mature to define LTS. But once customer started to deploy it, we must assure that there are patches/stable builds maintained and security holes and bugs fixed. Shebu: Everyone in the board supports the LTS, the question is to frame it (time). Dave: For now leave LTS out and mention the previous version as starting point. Abhishek: Sounds OK. Companies on older version will to thorough testing since they have products out already. Dave: Major, minor? Abhishek: Yes, only use Major and Minor. - Dave: testing, on the minor release that gets the hot-fix, what is the amount of testing? Need clarification. Anton: Normal CI testing is overnight, sanity tests, performance etc. All done on FVP. For release test, we ask "everyone" to test on their boards and we give the 2 week window for the testing. Dave: Once we have OpenCI in place, things could improve for hot-fix testing? Anton: Yes, that's our optimistic view on it. Abhishek: Automatic successful testing is not the problem. It's the failing that is the challenge. Board/device owner will have to help with investigations. Michael: Also important to add new test, testing the security fix. Will the test suite also be updated for old versions. Anton: If we provide a fix, do we want to keep the branch forever? Dave: How to get it to Phabricator? Abhishek: You can add it there yourself. Will help you with permissions etc.
Feedback from TSC reps - Abhishek: Looking for more feedback for the next meeting. - Joakim: Reminder that the email tsc@... is going to a public list seen by anyone https://lists.trustedfirmware.org/pipermail/tsc/. Abhishek: Will see if I'll create an internal Phabricator page.
-
Abhishek Pandit -
Shebu Varghese Kuriakose