Hi all,
Please see the announcement below regarding the first public release of the RMM implementation for the Arm CCA architecture.
The Trusted Firmware.org website will be updated soon, together with an accompanying blogpost!
Thanks
Matteo
From: Soby Mathew via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: 09 November 2022 13:32
To: tf-rmm(a)lists.trustedfirmware.org; tf-a(a)lists.trustedfirmware.org
Subject: [TF-A] Announcing TF-RMM v0.1.0
Hi Everyone
The TF-RMM team is pleased to announce the first public release of RMM implementation aligned to RMM Beta0 Specification [1] . The RMM is a software component that runs at Realm EL2 and forms part of a system which implements the Arm Confidential Compute Architecture (Arm CCA). The implementation can create Realm VMs in the Realm PAS and the Realm contents can be attested as specified in the RMM specification.
The official trustedfirmware.org git repo can be found at : https://git.trustedfirmware.org/TF-RMM/tf-rmm.git/. There is also a github read-only mirror and can be found at https://github.com/TF-RMM/tf-rmm . Contributions will be accepted via TF-RMM gerrit at trustedfirmware.org : https://review.trustedfirmware.org/q/project:TF-RMM%252Ftf-rmm
Please see the readme [2] and the getting started guide [3] to get started with RMM. We expect patches for supporting Realm Management Extension (RME) in linux kernel and related kvm-unit-tests to be available in the coming months. The patch to exercise Realm creation and execution via TF-A-Tests is in review at the moment [4] and the OOB instructions for the same can be found in TF-A RME documentation [5]. We expect these patches to be part of the upcoming TF-A v2.8 release.
The mailing list for the project is tf-rmm(a)lists.trustedfirmware.org<mailto:tf-rmm@lists.trustedfirmware.org>. Looking forward to fruitful community engagement and successful deployment Arm CCA systems in future.
Best Regards
Soby Mathew
PS : We hope to setup readthedocs documentation in the coming days, but till then , please bear with the github rendering of the rst documentation.
[1] https://developer.arm.com/documentation/den0137/1-0bet0/?lang=en
[2] https://github.com/TF-RMM/tf-rmm/blob/main/docs/readme.rst
[3] https://github.com/TF-RMM/tf-rmm/blob/main/docs/getting_started/getting-sta…
[4] https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/17221
[5] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/17610
Hi All,
Please find the November 17th meeting minutes attached.
Also please find attached both presentations referenced during the call.
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hi all,
Hi all,
Please find below the minute of the meeting for the TSC held on 20/10/2022, plus find attached the slide decks presented by Shebu and Anton.
Best regards,
Antonio
Attendance:
Eric Finco (STM)
Antonio De Angelis (Arm)
Anton Komlev (Arm)
David Brown (Linaro)
Dan Handley (Arm)
Shebu Varghese Kuriakose (Arm)
Kevin Townsend (Linaro)
Lionel Debeve (STM)
Kevin Oerton (NXM)
Julius Werner (Google)
Andrej Butok (NXP)
Matteo Carlini (Arm)
Thomas Sanderson (Infineon)
Presentation from Eric about STM usage and general direction of the projects on TF.org . Slide deck and meeting minute details available to TSC members only.
Next presentation about TF-M roadmap from Shebu
KevinO: Is the PSA Crypto Driver item a reference/open source implementation?
* Provides standard driver model API that implements PSA Crypto Client API. Driver API is what interfaces to HW
* Silicon Labs did one for their own driver in their SDK, but the one in TF-M for CryptoCell acts as an upstream reference
Memory usage and performance: first batch in April release, remaining optimisations to be released in TF-M v1.7
Default config to be switched to Base: SPM + platform (minimal skeleton TF-M) instead of having the full features in default build. But still three profiles (S/M/L)
Library mode to be deprecated and removed
KevinT: Something missing is the KConfig based approach, which is going to be really useful
* Yes, this is part of the "simplify configuration" bullet (on slide 4).
* Anton to discuss this later
ArotLess L2 Profile for customers request
* Which particular chip is going through the process with this Profile?
* Not specific, but very constrained platforms that support TF-M, SFN L1 isolation (small chips).
* The certificate will explicitly say that it will not support ARoT partitions.
* KevinT: Are there significant memory savings by just separating S and NS?
* Yes, mainly due to absence of IPC model, just SFN.
* Also no config for MPU and only TrustZone based. Memory/performance benchmarks should improve.
* KevinT: Will it still support main TF-M services?
* Yes. Profile medium for crypto i.e. symm and asym. is the base of this
Anton updated about KConfig support.
* Already presented in TF-M tech forum
* Addresses difficulty of TF-M configuration space (hundreds of options).
* There are build options and config options. Build options stay in cmake.
* Put anything not related to build in header files. Then move these options to KConfig system
* KConfig checks consistency, dependencies and set of options to generate the config headers
* Orange options are high level ones that OEM might tweak. Black is more TF-M internal stuff
KevinO: Are there implications of all this variability in terms of certification (i.e. re-usability)?
KevinO: i.e. what PSA certification assurance to customers get if they change config options?
* Shebu: PSA talks about required functionality; things like isolation levels. But doesn't mandate specific config options. This is implementation defined.
KevinO: Thinking about C-SIP certification. How reusable is the certification if they then change? Presumably the items in black wouldn't affect this?
* Shebu: Would need to talk about this on a case by case basis.
KevinO: Trend now is to do both C-SIP and PSA. With CSIP, it's composable. If you integrate any one of these modules with C-SIP cert, then how re-usable is C-SIP cert in product side, if we change this options?
* Shebu: Don't have a good answer for that. OEMs might not appreciate all these options and distinctions. Perhaps only allow control ones that matter most to an integrator rather than fine-grained config
* Anton: For a quite some time we don't have up to date CMSIS-pack. Part of this was due to the number of build options
* Anton: Reducing build options might help with feasibility of CMSIS pack.
Only thing missing in 2022 work is some of PSA ADAC support
* Eric: On CMSIS Pack. Will there be version of packgen in TF-M repo?
* Shebu: Packgen is missing some features, so want to enhance this in next months. Would include this in TF-M
* Might not be fully automated, though.
Eric: Are you thinking about a low power TF-M mode?
* Shebu: Not been looking at this. Would appreciate more details on that.
* Eric: Will get Lionel to send something here
* Anton: Are you concerned about power management or power reduction?
* Eric: Not sure of difference. Want to put TF-M in low power mode
Next item from roadmap rota should be: Mbed TLS in November meeting.
Hi all
The October TF TSC is tomorrow. The agenda topics we have so far are:
* ST use of Trusted Firmware and direction of travel (Eric)
* TF-M roadmap (Shebu)
Please let me know if you have any other topics.
Regards
Dan.
Hi All,
As TF is moving forward with a TF-A LTS per the proposals that have been
presented, I've created a new mail list for this purpose.
Please feel free to subscribe.
https://lists.trustedfirmware.org/mailman3/lists/tfa-lts.lists.trustedfirmw…
Thanks,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hi All,
Please see Joakim's notes from his recent OSFC attendance below. Thanks
for attending and sharing the notes Joakim. :)
Best,
Don
---------- Forwarded message ---------
From: Joakim Bech via Board <board(a)lists.trustedfirmware.org>
Date: Mon, 3 Oct 2022 at 01:20
Subject: [Board] OSFC 2022
To: <board(a)lists.trustedfirmware.org>, Okash Khawaja <okash(a)google.com>
Hi,
From Linaro, Ilias and I were attending the Open Source Firmware Conference
(https://www.osfc.io) in Gothenburg in September. As you remember
TrustedFirmware decided to sponsor the event again, so I was actually
attending on behalf of TrustedFirmware. I think it was a great event, one
of the best I've been at I think.
A common theme seemed to be "less is more", i.e., my impression after
listening to the talks and after having discussions with people, it feels
like people believe that various projects have had a bit too much feature
creep (BMC's and EDK2 was brought up a couple of times as an example).
Another issue is the slow response time on getting things fixed in BMCs,
Management Engines etc. On average it took 18 months to get reported
(security) issues fixed. Related was the complexity of having a lot of
other code running outside the main OS (again ME's, BMC's, dedicated
security blocks etc). General impression was that people would like to get
back into more controlled environments.
DICE [1] (RIoT) from TCG/Microsoft seems to be getting more attention and
it's starting to find its way into more devices. Recently we've heard this
being mentioned by a few independent companies as a possible and simple
lightweight solution to devices in need for some device identity and to be
able to do some measure boot without having to rely on a TPM device. We
(Ilias) presented DICE to the Linaro LEDGE group half a year ago as a
potential area of interest. We'll bring this up again to a greater audience
at Linaro and eventually we'll propose something that will affect TF-A .
The DICE engine could run in BL1 and the DICE core could live in BL2. If
that discussion matures, we'll have to bring it up to the TF TSC as well.
[1]
https://www.microsoft.com/en-us/research/project/dice-device-identifier-com…
There still seems to be a misconception about UEFI, that UEFI == EKD2. To
some extent I believe that we were able to communicate that U-Boot contains
tiny subset of UEFI, making it possible to boot EFI and that our end goal
with ongoing Linaro work is to make it possible to boot any Linux distro
(and possible also Windows) without having to make devices/platform
specific changes to the OS side. On this matter, we've also synced up with
Simon Glass at Google. As you know Simon is proposing an alternative
implementation called VBE, which has a different approach. In some sense
it's a cleaner and more simple solution, but we believe it will be hard to
reach the goal of running any distro without relying on device specific
customizations when using VBE.
Google (Thordur Bjornsson), mentioned challenges with attesting hardware on
the upcoming v9 (CCA). He claimed that Intel did that part right, although
the security solution around it later on was broken. I think we should
introduce him to Charles Garcia Tobin.
I briefly had a chat with Christian Walter (9element) who is one of the
OSFC organizers. He was grateful that TrustedFirmware sponsored the event
again and that we seemed to like their event.
Mullvad (Swedish VPN provider and also sponsor) released a new USB key
called tilitiskey [2]. They gave a demo where they authenticated a user for
a SSH session. Their solution is kind of built using DICE as well (they mix
in additional user provided data as well into the hash). We all got
engineering samples, it should be fun to see how that project turns out.
[2] https://www.tillitis.se
@Okash, perhaps you have something to share as well?
--
Regards,
Joakim Bech
| Distinguished Engineer | Technology and Product Management | Linaro |
| Mobile: +46 73 697 37 14 | Address: Scheelevägen 17, 223 63 Lund, Sweden |
--
Board mailing list -- board(a)lists.trustedfirmware.org
To unsubscribe send an email to board-leave(a)lists.trustedfirmware.org
Hi,
This is in context of earlier discussion about socialising TF-A more
widely, e.g. on LinkedIn and Twitter. I noticed that stackoverflow.com
didn't have a "tf-a" tag even though there are questions referring to
it. I have created it now.
Adding more questions and answers under this tag will also help in
socialising TF-A.
Best regards,
Okash
TL;DR: Attached is the TF-A LTS proposal doc. Please review and share
your thoughts.
Hello everyone,
Long term support for TF-A has a long history. As a community we have
flirted with it for a while, and like any flirtation, it started with
gossip -- in our case, over mailing list [1] -- more than two years
ago. Then Varun Wadekar did a wonderful tech forum presentation [2]
which demonstrated interest in the topic and raised interesting
questions about LTS.
After some time, the affair lost headline status, only to be revived
again [3], earlier this year. This time however, there is a formal
proposal (no pun intended). After the mailing list discussion and
feedback from TF-A tech forum [4], we have put together a draft which
attempts to give a concrete idea about what the TF-A LTS will look
like.
Please spare some time to read through it and share your feedback. The
plan is to put LTS into action this November.
Cheers!
Okash
[1] https://lists.trustedfirmware.org/archives/search?mlist=tf-a%40lists.truste…
[2] https://www.trustedfirmware.org/docs/TF-A-LTS.pdf
[3] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…
[4] https://www.trustedfirmware.org/docs/TForg_LTS_proposal.pdf
Hi All,
Please find the minutes to the Sept 15 TSC.
Best regards,
Don - sent on behalf of the TSC co-chairs
======================================
Attnedees: David Brown (Linaro), Thomas Sanderson (Infineon), Kevin
Townsend (Linaro), Lionel D (ST), Eric Finco (ST), Andrej Butok (NXP), Dan
H (Arm), Antonio (Arm), Bill Peckham (Google), Kevin Oerton (NXM.Labs),
Julius Werner (Google), Okash (Google), Matteo (Arm)
Agenda items:
* LTS
* RMM
* FW handoff spec
Recurring:
* OpenCI update won't be held as Glen/Don are not available today. See
backup in the redacted board slides sent out by Don for Open CI monthly
update.
LTS sum-up from board meeting
* until we start, it's hard to gain momentum and hard to estimate costs in
advance.
* TF.org to evaluate direct funding but only from the next financial year
* Proposal: share the burden for 1 LTS release to be maintained for at
least one year. To evaluate the effort, gather data, see how it goes,
evaluate the engagement, and then have data to propose to the board for
long term funding. Share the burden between companies interested.
* Question: which platforms are tested and supported? The baseline is the
one tested by the official TF-A releases, with those platforms available in
the OpenCI
* Board requests to carefully iron out the messaging to be shared with the
community around the announce of the LTS so that expectations are clear in
the community
* Tech-wise, the proposal does not seem to have any objection so this is
mostly around funding/maintainership topics at the moment
* Companies interested are now to meet and agree next steps
TF-RMM component
* Upstreaming expected November 2022. Plans on integrating TF-RMM in the
OpenCI in the longer term as well.
Is the code already visible? It's still private. Arm Architecture group
has some private prototype that was shared with some partners under NDA.
But different significantly from what we're planning to upstream.
* Is it completely separate or depends on other TF.org projects? It's
coupled with TF-A in the same way as Hafnium is. It implements RMM
specification, so Linux and KVM and other clients they need to support the
same version of the spec of RMM to be compatible
Is the KVM counterpart of RMM going to be upstreamed? Yes, but Arm not
the maintainer so actual upstreaming will take longer as Arm does not
maintain those projects. But there will be public branches with these
changes in the meantime
* KVM, EDK2, etc altogether available in November, they will follow their
own destiny in each project.
Is there a plan-B if upstream does not accept them? There is the risk but
hopefully we will try to minimize and does not come to upstream maintainers
as a surprise (discussions under NDA for years already with non-Arm
maintainers). It does not mean it will be quick and easy but confident that
it will happen. For example one particular concern is the major work going
on in Android pKVM. Might risk some conflicts that slow down upstreaming
FW Handoff spec
* Several discussions around this happened so far. A number of interested
parties (e.g. uboot). Quite difficult to accommodate all requirements from
different parties. This is a tentative to summarise and centralise the
discussion so far to foster further collaboration and evolution of the
spec. We start on TF.org then we will re-assess if this the best place (or
needs to be moved to GitHub or other places).
* Contribution model: similar to other projects but with indepedent
maintainers, no strong links to other projects
* Creative commons license as it's more user friendly.
* Unless a big objection this is what is going to happen in the next weeks
* Is the format not pinned to devicetree? The spec just talks about
container format, the actual data can have different practical formats. It
tends to accommodate different implementation details. It's more focused on
the information itself rather than formats to organize this information
(i.e. registers to use, etc). It's quite a simple spec
* The spec will allow to specify different formats for the practical
structures that hold the information
Are there plans to add also tftf-tests for RMM? Yes there are some
additional tests that will be upstreamed.
* There are some changes in TF-A for example that are already happening
upstream in preparation for November 2022
Agenda items finished, no further objections.
Discussion about what will happen in subsequent meetings.
1. Roadmap sharing: Start again with TF-M (action item: inform Shebu and
invite for October (last presentation was in February)
2. Members inform about their usage (e.g. Kevin from NXM did very good
presentation last round) of TF.org projects, we believe it can be
beneficial for the community. Call to major partners in the call if there
is something you might be considering.
TSC interested especially in hearing about any particular challenge that
you need to overcome to use the projects commercially, any
suggestions/lesson learnt that can benefit the different projects in terms
of technical direction. Not necessarily to public TSC, can be a members
only TSC (and share public/open info only)
Feel free to reach out (directly to us in private if not comfortable)
STM: We can do that for some of the projects of TF.org (what we use).
Some direction, what we think it's difficult, what can be changed in terms
of direction.
Is there anything else members would like to have in future TSC?
No particular feedback.
Last clarification about the structure of mailing lists. TSC-Private is the
members only invited to the meeting.
TSC is for public attendance (no filter). Don has re-organized recently so
hopefully minutes of meetings will have been correctly archived in the list
manager now.
No particular other business, meeting close.
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
