Reminder - might be of interest to some.
Don
---------- Forwarded message ---------
From: Kristine Dill <kristine.dill(a)linaro.org>
Date: Thu, 17 Jun 2021 at 05:56
Subject: Re: View the agenda and register for Linaro and Arm CCA Tech Event
on June 23
Hi all,
This is a reminder to register for our event next week: Linaro and Arm CCA
Tech Event, Deep dive into the Arm Confidential Compute Architecture
<https://www.linaro.org/events/linaro-and-arm-cca-tech-day-deep-dive-into-ar…>
.
The event is free and open to the public so feel free to share with any
developers who may be interested.
The registration link and schedule can be found here:
https://www.linaro.org/events/linaro-and-arm-cca-tech-day-deep-dive-into-ar…
The event has 6 sessions and starts at 14:00 UTC on June 23 - the schedule
should pick up your local timezone.
Once you register, you'll receive an invite to login to the event platform
PINE on Monday (2 days before the event).
All sessions will be presented live and the platform has a Q&A and chat
window so you can ask questions and interact with the speakers and other
attendees during the event.
Thanks and let me know if you have any questions!
Kristine Dill
Events Manager
Linaro
On Wed, May 26, 2021 at 10:40 AM Kristine Dill <kristine.dill(a)linaro.org>
wrote:
> Hi everyone,
>
> The agenda is now available for viewing and registration is open for the
> Linaro and Arm CCA Tech Event on June 23! View the agenda and register on
> the event page here:
>
>
> https://www.linaro.org/events/linaro-and-arm-cca-tech-day-deep-dive-into-ar…
>
> The schedule widget should pick up your local timezone. The event begins
> at 14:00 UTC. This event is free and open to anyone, so feel free to share
> the link publicly.
>
> For those who can't attend, videos of sessions will be made available
> after the event on the Connect Resource Page. We'll be using the same
> software we used for Linaro Virtual Connect 2021 (PINEtool.ai). If you've
> registered, you'll receive an email invite from PINE when we get closer to
> the event on June 23.
>
>
> Thanks and let me know if you have any questions.
>
> Kristine
>
>
>
> <https://www.hubspot.com/email-signature-generator?utm_source=create-signatu…>
>
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
>
