Hi All,
Any agenda items for this week's meeting?
Following topics from previous meeting -
* TF-M security patch release.
Have the teams agreed on this and is this now concluded?
* TSC feedback
I have created a page where people can add their inputs. It is open at the moment, if you feel there is a need to restrict visibility then please let me know.
https://developer.trustedfirmware.org/w/collaboration/community_development…
Thanks,
Abhishek
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.
There is the one pending from the previous meeting:
* [Tentative] Trusted Services roadmap presentation. I am checking availability within Arm as this is short notice.
Regards,
Eric Finco
[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: logo_big5]
Eric FINCO | Tel: +33 (0)2 4402 7154
MDG | Technical Specialist
ST Restricted
From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Abhishek Pandit via TSC
Sent: lundi 17 mai 2021 13:00
To: tsc(a)lists.trustedfirmware.org
Subject: [TF-TSC] TSC Agenda 20 May 2021
Hi All,
Any agenda items for this week's meeting?
Thanks,
Abhishek
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(a)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
Following on the agenda for tomorrow
* TF-M security vulnerability and patch release policy, providing fixes for security issues for past releases. [Dave Cocca]
* optee.org transition to trustedfimrware.org. [Joakim Bech]
* [Tentative] Trusted Services roadmap presentation. I am checking availability within Arm as this is short notice.
Thanks,
Abhishek
From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Abhishek Pandit via TSC
Sent: 13 April 2021 12:21
To: tsc(a)lists.trustedfirmware.org
Subject: [TF-TSC] TSC Agenda 15 Apr 2021
Hi All,
Any agenda items for this week's meeting?
Thanks,
Abhishek
Hi,
On Tue, 13 Apr 2021 at 13:29, Joakim Bech via TSC <
tsc(a)lists.trustedfirmware.org> wrote:
> Hi,
>
> Timely, I had this written in another email :-)
>
> optee.org (on purpose) doesn't contain much information of value. We
> removed duplicated and stale information quite some time ago and now the
> only thing that is really left of value there is the security advisories.
> So, I want to redirect optee.org to trustedfirmware.org/projects/op-tee.
>
> I don't want to get rid of optee.org (and op-tee.org), since there is
> branding value in those. I simply want to remove our current page and
> redirect to TrustedFirmware.org. Redirection is easy, however, we need to
> figure out where to host the security advisories. We could either store
> them directly accessible under a trustedfirmware.org as a sub-page or we
> can put them somewhere under our existing security pages at Phabricator. So
> as a topic for tomorrow, I'd like to hear whether you're against me
> redirecting this and have a discussion about what to do with security
> advisories. Right now OP-TEE and other TF-projects are spread out on
> various sites.
>
> Then with the recent Armv9 announcement, I wonder if we as a group already
> now need to start thinking about what we need to do with the project under
> TF? I would be surprised if we don't have to do anything as a collective
> group.
>
In addition to that, we from Linaro are also interested in the roadmap and
associated timelines for the Trusted Services project. If someone (from Arm
I suppose) has information about that ready to be shared, then that's a
third thing that could be covered on Thursday.
Regards,
Joakim
>
> Regards,
> Joakim
>
>
> On Tue, 13 Apr 2021 at 13:20, Abhishek Pandit via TSC <
> tsc(a)lists.trustedfirmware.org> wrote:
>
>> Hi All,
>>
>>
>>
>> Any agenda items for this week’s meeting?
>>
>>
>>
>> Thanks,
>>
>> Abhishek
>> --
>> TSC mailing list
>> TSC(a)lists.trustedfirmware.org
>> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>>
> --
> TSC mailing list
> TSC(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>
Hi,
Timely, I had this written in another email :-)
optee.org (on purpose) doesn't contain much information of value. We
removed duplicated and stale information quite some time ago and now the
only thing that is really left of value there is the security advisories.
So, I want to redirect optee.org to trustedfirmware.org/projects/op-tee.
I don't want to get rid of optee.org (and op-tee.org), since there is
branding value in those. I simply want to remove our current page and
redirect to TrustedFirmware.org. Redirection is easy, however, we need to
figure out where to host the security advisories. We could either store
them directly accessible under a trustedfirmware.org as a sub-page or we
can put them somewhere under our existing security pages at Phabricator. So
as a topic for tomorrow, I'd like to hear whether you're against me
redirecting this and have a discussion about what to do with security
advisories. Right now OP-TEE and other TF-projects are spread out on
various sites.
Then with the recent Armv9 announcement, I wonder if we as a group already
now need to start thinking about what we need to do with the project under
TF? I would be surprised if we don't have to do anything as a collective
group.
Regards,
Joakim
On Tue, 13 Apr 2021 at 13:20, Abhishek Pandit via TSC <
tsc(a)lists.trustedfirmware.org> wrote:
> Hi All,
>
>
>
> Any agenda items for this week’s meeting?
>
>
>
> Thanks,
>
> Abhishek
> --
> TSC mailing list
> TSC(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>
Hi TF Board/TSC
You may have seen the below invite on the TF-A or OP-TEE lists but I'm just forwarding directly in case you missed this. If you have an interest then please contact François-Frédéric directly.
Regards
Dan.
From: François Ozog <francois.ozog(a)linaro.org<mailto:francois.ozog@linaro.org>>
Sent: Thursday, April 8, 2021 12:59 PM
To: TSC <tsc(a)linaro.org<mailto:tsc@linaro.org>>
Subject: Invitation to OP-TEE functional safety workshop
Hi,
Linaro is conducting an opportunity assessment to make OP TEE (open platform trusted execution environment) ready for functional safety sensitive environments.
The scope of this analysis also covers Trusted Firmware and Hafnium even though we will not try to produce a plan for their own safety readiness.
We’re organizing a 2 hours workshop on April 15th 9am CET to present the state of the research, discuss the key use cases, and brainstorm on possible requirements for a Long Term Support program.
The first use case is to use the TEE to boot a safety certified type-1 hypervisor. We are also considering other use cases - for example, a safety payload could be loaded as a Secure Partition on top of Hafnium with OP-TEE or Zephyr used as a device backends.
Agenda (to be refined)
* Vision
* Use cases discussion
* What is the right scope?
State of the research <https://docs.google.com/presentation/u/0/d/1jWqu39gCF-5XzbFkodXsiVNJJLUN88B…>
* “Who does what” discussion (LTS, archiving...)
* Safety personnel (Linaro and contractors) discussion
* Other considerations from participants?
* Community organizations and funding?
* Closing and next steps
(preliminary content can be found in the attached document, the goal will not be to go though all slides but to use them to guide the discussion)
We have contacted key partners in the Arm ecosystem as well as Tier 1 and car makers and we would like to invite you to join our workshop: we would highly appreciate your contribution. If you are interested or if you would recommend anyone from your team, we will be pleased to send a calendar invite with the bridge details.
Looking forward to hearing from you soon
François-Frédéric
--
[https://drive.google.com/a/linaro.org/uc?id=0BxTAygkus3RgQVhuNHMwUi1mYWc&ex…]
François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group
T: +33.67221.6485
francois.ozog(a)linaro.org<mailto:francois.ozog@linaro.org> | Skype: ffozog
