Hi All,
FYI, the Call For Participation(CFP) deadline for this year's OSFC in
Sweden is very near. If you or others on your team are interested,
the proposal
submission page is here <https://talks.osfc.io/osfc2022/cfp>.
The in-person conference is scheduled for mid-September.
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hi All,
The CFP deadline for Arm Dev summit is in a couple days- Thursday 23 June.
I realize this is last minute, but still wanted to make sure you were all
aware in case you had a topic to present.
Here is the link to submit
<https://devsummit.arm.com/flow/arm/devsummit22/cfpinfo/page/details>,
Best regards,
Don
Attendees:
Glen Valante (Linaro)
Antonio de Angelis (Arm)
Matteo Carlini (Arm)
Kangkang Shen (FutureWei)
Andrej Butok (NXP)
Dan Handley (Arm)
Julius Werner (Google)
Bill Peckham (Google)
Kevin Oerton (NXM LABS)
Brandon Hussey (Renesas)
Eric Finco (STMicroelectronics)
Meeting start, Dan introduces.
- [Matteo] First we'll talk about CCA - same presentation already given to the board.
- Don't share roadmap slides normally, but we are not going to talk about anything confidential information anyway. We'll cover where we are and where we're going with the CCA architecture.
- Realm Management Extension (RME) in v9 - realm world is distrustful wrt NS and S, EL3 becomes the Root World. This is the Arm way of doing confidential compute, a well-known practice in the industry.
- Changes relating to RMI interfaces already happening in TF-A latest release. There will be changes in Linux kernel, in EDKII as the reference implementation of UEFI; focus on infrastructure systems first.
- TF-RMM will be our implementation of Realm Management Monitor software component: it will be a new project part of the TF.org family; already introduced to the board
- Outside of the application processor: RSS (runtime security subsystem) firmware will be upstreamed to TF-M project
- RSS is the HW root of trust that implements the HES (Hardware Enforced Security) requirements of the Arm CCA Security Model.
- RSS is going to appear on mobile client platform first (it will be enabled on its own without the rest of HES/CCA)
- [Kangkang]: We looked at CCA, 100% full implementation might be taking a long time. Stages and status of different software components?
- [Matteo] I will describe the various components and how we will start to demonstrate some of the components on a fast model platform soon.
- RME EL3 implementation first appeared in TF-Av2.6
- Specification will be public and published around end of June on developer.arm.com - if delay, beginning July
- [Dan]: This means the RMM spec for SW (the architecture specs are already out)
- [Matteo] All components and interfaces must be aligned towards the same interface version - currently non-public alpha, so that when beta goes public realigned work is needed
- (4-5 upstream components aligned against the public beta released spec)
- The timeline is roughly H2 2022 (CY22Q4 for upstreaming to start) kernel/kvm, edk2, rmm in tf-org]
- Quality level still not finalised (0.1, or better)
- Hafnium/TF-A EL3/TF-RMM will need to be aligned to be able to communicate
- Spec will be EAC end 22 beginning 23 - will need to realign components against EAC then
- In H2 2023 advanced 1.x features of the spec will start to be implemented
- [Kangkang]: Remember our experience in TrustZone, implementing Secure World (EL3), Trusted OS and secure applications one at a time.
- Why do you focus on the complete set of components instead of just picking a single use case / component and expand gradually on this?
- CCA looks like all components are planned and need to work together and be aligned and implemented. Why not just start with simple use case (CCA application) and then expand?
- [Matteo]: It's the architecture itself that has such extensive requirements. It's already an MVP. Very basic use case. You can't go simpler than this.
- [Matteo] You need to have several components in place otherwise it won't work, but we're just giving basic building blocks without trying to overstretch.
- [Dan]: Agree, it's a lot of components, but they are all needed for the key initial use-case: Boot guest VM from encrypted disk into a realm protected from host access.
- [Kangkang]: it's important to demonstrate how to use as soon as possible. Showing the full picture but implemented gradually
- [Matteo]: RME extension is available on latest publicly accessible architectural model (Base FVP) - allows you to play with these features.
- Qemu work ongoing (towards the end of the year). Emulation functionality is being assessed by virtualisation team of Linaro.
- Arm will provide publicly available solution FVPs, containing all System IP (CPU, GIC, interconnect, GPU for mobile for example)
- Infrastructure FVP will contain all IPs needed to demonstrate CCA.
- [Glen]: OpenCI status update; this has been moved from board to TSC to reduce technical details shared in board meeting.
- Boards going into lava lab. Rack still being built to add more boards; ST boards going in next week or two.
- After that it's Renesas, although still waiting on Renesas on the availability of the SW.
- Board meeting required to discuss other boards that need to be made available.
- [Eric]: as we discussed: additional candidate board coming from ST but no pressure. Any timing?
- [Glen] From a Sw point of view we're almost ready; but need to check latest readiness internally. Glen on standby for updated timeline to plan accordingly.
- Mbed TLS in openCI:. Some stability issues with Windows, need to upgrade the CI platform - will allow stability and performance increase
- PSA ACK tests enabled, but still have failures. Working with Arm to fix them.
- Code coverage: going through docs and code coverage reports to have source links (got completed last week)
- Will do MISRA enablement after code coverage and PSA ACK tests. Starting with TF-A. Create a series of milestones and estimates. Published plan and resourcing.
- Having biweekly meetings -> maybe going to weekly to keep up the pace.
- Getting licensing in place now. Discussions and emails ongoing for licensing infrastructure. Several weeks work for that before prototyping can start in staging.
- Then onto production. Several issues closed/fixed.
- [Dan]: Is the resource/plan public? I did not see numbers.
- [Glen]: Updated the plan two days ago with resource, check again. TFC-10 contains actual work tasks and first two milestones.
- [Dan] Is this waiting for review and approval?
- [Glen] Already reviewed from Arm and Linaro.
- [Dan]: What's the status of the ticket for read only mirrors on GitHub?
- [Glen]: need to check offline.
- [Dan]: The plan going forward is for OpenCI details to be in TSC and feedback from TSC back to board. Is there any feedback for the board yet? Anything offline is fine as well.
- [Dan]: Next time would be good to focus on what are the big things in the backlog, what are the next important things planned, etc (i.e. 6 months medium term roadmap).
- [Glen]: we presented that detail to the board meeting. will move from the board meeting to the TSC meeting next time.
- Any questions / AOB?
- None. Meeting end.
Hi all
We have these topics so far for the TSC meeting tomorrow. Please let me know if you have any more.
* Arm CCA roadmap update
* Open CI update
(Note, there is a plan to discuss the LTS topic in the TF-A and TF-M tech forums so I didn't put this as an agenda item here, but we can discuss this needed).
Regards
Dan.
Hi all
We have these topics so far for the TSC meeting tomorrow. Please let me know if you have any more.
* Combined OP-TEE and Trusted Services roadmaps (Julianus and Shebu)
* Open CI Update
* Discussion on whether this should be a recurring topic
* Discussion on what board info should be shared with TSC
Regards
Dan.
Hi,
Please find Apr 21 minutes below:
Thanks - Sent on behalf of the TSC co-chairs
Don
Attendees: Kevin Oerton(NXM), David Brown(Linaro), Kangkang
Shen(Futurewei), Julius Werner(Google), Andrej Butok(NXP), Dan
Handley(Arm), Okash(Google)
Minutes:
-
TF-A Roadmap update: Matteo
-
Walked thru roadmap page
-
https://developer.trustedfirmware.org/w/tf_a/roadmap/
-
Don: Can be found from the https://www.trustedfirmware.org/faq/
page as well.
-
Plan to keep this page up-to-date
-
Note the in-development section that shares active engineering
activities.
-
Okash: Heard there was a push to make Hafnium compulsory. Is the EL3
SPMC a stop gap?
-
Matteo: Depends on use cases for TZ enablement. Google not
mandating FF-A to the best of my knowledge. From Arm POV, if
you want to
isolate the normal world from malicious TAs/TEEs, Arm recommends using
Hafnium Secure-EL2 reference.
-
Okash: S-EL2 adds code/architecture complexity. Need an IOMMU that
supports S-EL2. Must look at tradeoffs. If OEMs want other
secure VMs, I
can see the advantage. Would all vendors want this? Is there
an option not
to use this (secure EL2) solution?
-
Matteo: Yes, TF-A doesn’t impose mandatory Hafnium usage. Can
still use other SPM configs. From an upstream POV, there’s a
limit to the
long-term support for all the different configs. We can’t
promise that EL3
SPMC will still be supported upstream in 2-3 years (though it
can still be
used downstream).
-
DanH: If there’s partner demand for long term support of the EL3
SPMC, we’re open to other non-Arm maintainers helping out.
-
Okash: Deprecating EL3 SPMC would send the message that Arm thinks
partners should move to Hafnium (S-EL2). Not deprecating
implies partners
can choose.
-
Matteo: Some components in TF-A aren’t maintained by Arm.
-
Okash: Any discussions on long-term LTS releases?
-
Matteo: Has been discussed in the past, also in a previous tech
forum. This lost traction, but a recent security issue
(Spectre-BHB) has
brought it back. Arm isn’t in a position to maintain it
ourselves. We can
discuss lighter options, like hotfix releases to most recent tagged
release, as recently added to TF-M. Could do similar in TF-A.
Must consider
the cost of various options..
-
Okash: Can look at the phone ecosystem as an example starting
point for what is required. Could provide a rough gauge for
how many years
an LTS needs to be maintained.
-
Dan: The cost of emulating the phone ecosystem would be high, for
example you’d need to backport bug fixes to 3 year old
releases. As Matteo
says, this would be too much for Arm on its own. Partners
would need to
share those costs.
-
Okash: Google is interested but would also need other partners too.
-
Don: There’s a CI cost as well?
-
Dan: Yes
-
Matteo: Could this be a future TSC topic?
-
Dan: May be a good maillist topic so that non-members can chime
in.
-
Okash: I restart the thread on the TF-A mailing list.
-
Matteo: reviewed ongoing/future tasks
-
MISRA tool integration into OpenCI now planned. Arm will remove
reliance on internal instructure.
-
See tech forum recording on DRTM here:
https://www.trustedfirmware.org/meetings/tf-a-technical-forum/
-
KangKang: How often will the roadmap be updated?
-
Matteo: It’s a live doc. Will try to update every quarter, but at
least every 6 months. These roadmap presentations are roughly every 6
months.
-
Dan: TSC survey feedback: Should Open CI tasks be reviewed in TSC or
Board?
-
Matteo: Not much discussed in the Board meeting. Perhaps high level
strategy in Board and ticket/plans reviewed by TSC?
-
Dan: Should Board minutes be shared w/ TSC?
-
Don: Ask the Board?
-
Planned future TSC topics
-
OP-TEE
-
Action: Next session is an OP-TEE review. Don reach out to Rushika
-
Trusted Services: by Shebu
-
Open CI - a potential backlog/roadmap review in this round robin
review
<end>
Hi all
So far we have the following topics for tomorrow's TSC meeting. Please let me know if you have any others.
* TF-A roadmap update
* TSC survey feedback
* GitHub mirroring update
Regards
Dan
Hi All,
Please find the March 17th TSC minutes below. Dan's slides regarding
Github from the meeting are also attached.
Best regards,
Don
========================================================
Attendees: Don Harbin, David Brown (Linaro), KangKang Shen (Futurewei),
Antonio De Angelis (Arm), Dan Handley (Arm), Shebu Varghese Kuriakose
(Arm), Andrej Butok (NXP), Anton Komlev (Arm), Kevin Oerton (NXMLabs), Dave
Rodgman (Arm), Julius Werner (Google), Kevin Townsend (Linaro), Eric Finco
(ST), Okash Khawaja (Google)
Actions:
-
Anton: Check feasibility of changing PSA Crypto header folder name.
-
Anton: Gauge interest in various GitHub options for TF-M
Minutes:
MBed TLS Roadmap (Shebu): Presented his slides
-
Continuing to look for support from members in the review role since
there’s a large load. Several members have stepped up - could still use
some additional support.
-
Kevin Townsend: Have we made any progress making PSA Crypto headers
work across projects?
-
Anton: No mismatch between MBed TLS v3.1.0 and TF-M
-
Antonio: TF-M’s headers are good now. Public headers are aligned
between TF-M and MBed TLS. Some headers are private to implementation, so
there’s not much we can do there.
-
Andrej: Can we change the folder name for one of the projects, so
that we don’t get conflicts in projects that build both sets of headers?
Could be either Mbed TLS or TF-M, but it’s important for them to be
different. Tfm_psa for example.
-
ACTION Anton: Check feasibility of changing PSA Crypto header folder
name.
-
Dave Rodgman: Getting good engagement/involvement. Agree review
contributions are very helpful
-
Andrej: What is the best place for companies to upstream their own PSA
Crypto drivers?
-
DaveR: Mbed TLS doesn’t plan to host h/w specific drivers.
-
Andrej: Somewhere in TF-M or create own repo?
-
Antonio: There are some PSA Crypto drivers in TF-M platform folder.
Would this make sense?
-
Andrej: What about products that don’t use TF-M?
-
Andrej: Could provide in own SDK or a separate repo on github. We’ll
probably go with the latter. We’re getting customers wanting to use the
upstream.
-
Anton: TF-M allows use of external projects. Github seems the right
place.
-
DanH: In future there may be value in TF.org providing full platform
stacks where stuff like this could live. Part of the problem here is that
TF-M and TF-A already have platform interfaces and host platform
code, but
Mbed TLS is a generic library with no platform interfaces.
-
Shebu: We also need to get MBed TLS tested on real target h/w in Open
CI
-
See the MBed TLS roadmap for more.
-
Don: reminder - new FAQ points to roadmaps page:
https://www.trustedfirmware.org/faq/
Current GitHub Status: Dan Handley
-
Presented status slides
-
Dan: Will be moving MBed TLS repos to a TF-owned org account vs
Arm-owned in the next few weeks.
-
Dan: TSC previously decided that all TF projects should have a GitHub
presence, even if some projects (e.g. TF-A) retain Gerrit for review
-
Andrej: Was this a TSC decision?
-
Dan: Yes. Unfortunately progress got blocked on funding an investigation
into a hybrid Gerrit/GitHub solution. But other solutions are possible.
-
Dan: NXP/Linaro especially keen for TF-M to move to GitHub
-
Andrej: Would like TF-M to fully move to GitHub (not just a read-only or
hybrid solution)
-
Andrej: Agree it will help contributions. We believe this will make TF-M
more popular
-
David Brown: Recently had difficulty creating a simple change for
review. GitHub will remove blockers in pushing changes.
-
Dan: GitHub access from China is more difficult, but solvable with VPN
-
Antonio: Could have a repo mirror in TF.org infrastructure to remove the
VPN dependency?
-
David: Providing a read-only mirror is simple enough
-
Dan: But what about providing a seamless GitHub experience.
-
David: That’s a much harder problem to solve.
-
Andrej: MBed TLS doesn’t have a problem, then it should be OK for TF-M
as well
-
Dan: It’s a problem for all GitHub projects
-
Kangkang: Most big China companies have their own VPN. Mainly a problem
for smaller companies.
-
Dan: Even if we decide that fully migrating to GitHub is the way to go,
this requires a lot of work from Arm to move internal systems to GitHub,
which we can’t do for some months. Could we create a read-only mirror as a
stepping stone and see if this improves engagement?
-
Kevin: We won't be able to measure success from a read-only mirror, but
it’s still a good stepping stone.
-
Antonio: Can at least measure attempted pull requests, even if they
can't be merged.
-
Kevin: It would also be useful to link to GitHub from related projects.
-
Dan: We should also check if fully moving to GitHub eventually is what
TF-M contributors want
-
ACTION Anton: Gauge interest in various GitHub options for TF-M
-
DanH: Secondary issue is our dependency on deprecated Phabricator.
GitHub provides a solution for migrating content out.
-
Agreement: Pursue the read only mirror. Objections?
-
None heard.
Hi all
We have 2 topics so far for the TSC meeting tomorrow. Please let me know if you have any more.
* Mbed TLS roadmap
* Continuation of the "Using GitHub" discussion (especially for TF-M). This got bounced back from the board to the TSC.
Regards
Dan.
