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.
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.