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
