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.
