Hi All,
Please find the meeting minutes from the Jan 19th meeting attached.
Also find the presentations and supporting content from Julianus (OP-TEE
updates) and Kevin Oerton(EU Cyber Resilience Act & ENISA Good
Practices...) attached.
Thanks and best regards
Don - Sent on behalf of the TF TSC co-chairs
Hi all
The agenda so far for Thursday's TSC is:
* OP-TEE roadmap (Ilias, cc'd)
* EU Cyber Resilience Act analysis (KevinO).
Let me know if you have any other topics.
Regards
Dan.
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
