FYI for any of you that missed the CCA event and are interested in watching
the recordings.
Don
---------- Forwarded message ---------
From: François Ozog <francois.ozog(a)linaro.org>
Date: Thu, 24 Jun 2021 at 07:53
Subject: Arm/Linaro confidential computing architecture event resources
Hi
The recorded event is available at:
https://connect.linaro.org/resources/arm-cca/
This has been a great event with deep technical content.
A key element is the enablement through the Verifier which allows a third
party to play a trust role between the cloud customer and the cloud
provider. It has been the missing link of all processor vendor proposed
confidential computing technologies I've seen so far. An open governance
project is associated: https://github.com/veraison
Cheers
FF
Hi All,
Please find minutes/actions from last week's TF TSC below.
If any questions or corrections, please let me know.
Best regards,
Don Harbin - sent on behalf of TF TSC Chair
Attendees: Don Harbin, Abhishek Pandit, Kevin Oerton, Dave Cocca, Eric
Finco, Julius Werner, Joakim Bech, Kevin Townsend, Dan Handley, Michael
Thomas(Renesas), David Brown
Action Items:
-
Abhishek: Keep the TSC informed of important decisions made.
-
Abhishek: Check to see if Tech Leads can come in and present plans.
-
Don: Ask the board if they need items from TSC.
-
Abhishek: Discuss with Tech Leads about participating in the TSC and
informing about major changes. Present results at next TSC.
-
Abhishek: Plan bi-annual roadmap discussions and the possibility of
public versions in TSC
-
Abhishek: Add “Phabricator transition planning” as a future TSC agenda
item.
-
*Abhishek*: Create a wiki space for TSC members to provide ideas on what
they would like to see in the TSC meeting.
Minutes:
-
TF-M Patchlist proposal
-
AP: Should this be left for today? About TF-M tightening up the
wording?
-
DC: Sounds OK. It seemed OK, the main issue is that we would like to
tackle the LTS issue - as brought up in the Board meeting.
Understood this
may require additional funding
-
AP: Waiting for TF-M PL team to approve. Once they confirm, Plan to
move forward. Haven’t heard, so I will bring up in the next meeting.
-
TSC Feedback
-
AP: Will create a page for members to comment on. Would like comments
-
https://developer.trustedfirmware.org/w/collaboration/community_development…
-
TSC decision for returning TF projects to Github
-
DanH: Agree a good idea, but want to continue Gerrit use. May want
to re-look given feedback.
-
JB: Summary - don’t have technical agenda or discussions - taking
place in other forums and 1:1’s. The items are happening in
other places.
Much is around CI and testing, so if not leading Architecture
and testing,
should we change goals of TF?
-
JW: Agree, processes in other meetings. Perhaps accept that and
evaluate the value of this TSC.
-
EF: Mentions iotmint comment he made. We could give it a try and use
meeting for lookahead? Or is open forum a better format? Should these
open forum items be discussed in this TSC?
-
AP: The technical top level SC to have lightweight topics that cross
projects? There are multiple issues that are common and need to be
handled. If push to board, that’s fine. Having more technical topics in
this TSC - a good thing in general, but they need to be
proposed. Between
Dan and Abhishek, they can handle most topics. So how should Technical
proposals come into TSC?
-
EF: Miss a place where we can discuss what we’re thinking. Sometimes
in Open Forums, but not always in the best format. Where topics
come from
- most of the inputs coming from Arm on significant developments.
-
DanH: Some things that Arm can bring to the table, but they are
semi-periodical. After that, for example, we could discuss the
outputs of
CCA event happening next week.
-
AP: IF someone asks for an Arm expert to present, this is
reasonable. But we need to have members proposing desired
topics. Roadmap
is a good round robin topic - need to have tech leads attend. But deeper
technical topics are still unclear. All TSC members can invite outside
people to present. Agenda comes from members
-
DanH: Roadmaps could be a recurring topic.
-
AP: Roadmaps are on a 6 month cadence, so not a monthly thing
-
MT: TF.org handles tf-m and tf-a. TF-M is more self contained
regarding dependencies vs TF-A.
-
AP: Yes, A has multiple projects in the stack
-
MT: For TF-A, is there coordination between the multiple stacks? OP
TEE for example. Are there cross project discussions?
-
JB: Tends to be 1:1 communications. Is this the forum to add others?
-
MT: Is there a benefit to at least present this in TSC?
-
JB: Makes sense to present merged roadmap views.
-
MT: Probably other examples.
-
AP: Purpose of TSC previously discussed and wanted to keep it light.
If multiple methods, discuss in TSC, else don't get involved. Should TSC
steer any decision making?
-
EF: Back to Michaels example on mbedtls - where should this take
place.
-
MT: A summary of changes being made to x or y project, would help.
-
AP: Where should we have these active conversations? In TSC or
elsewhere?
-
MT: Don’t want tech leads to come in regularly, but occasionally not
a bad idea. As SC, to steer at the right time with right information, SC
can provide the input.
-
AP: Can make a draft to suggest how the TSC could get involved at the
suggested level. So Cortex-A discussions every few months?
-
MT: How does it happen now? Decisions made autonomously per project?
-
DanH: Tech Leads for solutions do discuss in Arm, but a case that
some of these discussions could be brought outside of Arm to TSC.
-
AP: Multiple components.
-
DanH; A proposal to look at solutions in TF.org. Step changes may be
required.
-
AP: Action: Have TSC remain informed of important decisions?
-
DC: Also important topics on the table that want SC and Members to
shape the decision. Aligns with Roadmap - as decisions made,
vet with TSC
to meet member objectives.
-
AP: Possibly if TSC is interested in OP TEE, then join OP TEE Tech
Forum. Or discuss in TSC? Two possibilities.
-
DC: Have resource conflicts. TSC must have enough about overall org
to steer.
-
AP: Agree. Shouldn’t just be informed afterwards, but get involved
earlier to “steer” Have discussed MISRA compliance in the past.
-
MT: A roadmap discussion is a good starting point.
-
DC: Key off milestones in roadmaps can determine when a topic should
be discussed.
-
AP: Action: Need to see if Tech Leads can come in and present plans.
-
DanH: Comes back to how a project is driven forward. By Arm? By
others? A roadmap can be lopsided. What is missing is Tech Mgr/Roadmap
owners across all projects. Arm Tech Mgrs may not always be receptive to
requested changes
-
DC: If someone is not participating, then inputs carry less weight.
-
JB: A look at the product today, mainly Arm/Linaro that drives much
of it. OP TEE roadmap is driven from Linaro Members, for
example, so what
does it mean for TF to own a project?
-
AP: There is an opportunity where if someone brings a topic in, then
a different model. A proposal comes to the table. Then discussed.
-
JB: OP TEE - “can I see roadmaps?” “Talking to Linaro” doesn’t seem
like a good answer.
-
AP: OK with roadmaps to be driven from other orgs.
-
AP: 2 Actions:
-
What do we ask Tech leads to inform
-
How to discuss items in advance on roadmap
-
Think Matteo/Shebu post roadmaps, but can ask if don’t
-
JW: Still not sure how affective the TSC can be with external
activities driving things
-
AP: Aligning w/ Eric’s input and take votes to the board.
-
EF: Still see some potential value on what is happening.
-
JW: Could be emails?
-
AP: Could take this to Tech Leads in Arm and get their thoughts on
willingness to discuss work items.
-
DC: worth a try to see if it could add value.
-
JB: Once example if companies presenting Security incidents on their
own pace. Wanted to publish June 24th, Joakim explained and
they pushed to
July 10th
-
DanH: Need to add Phabricator to the future agenda.
-
AP: *Action*: Ask the board if they need items from TSC.
-
DanH: Off line feedback would be OK.
-
AP: May create a Q & A.
<end>
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
>
