Hi Joakim
Thanks for the report – interesting reading! I have a few comments:
> Another issue is the slow response time on getting things fixed…
Firmware updatability is a long running issue in the industry. Linaro and TrustedFirmware have a big role to play here.
> General impression was that people would like to get back into more controlled environments.
Controlled by who? I suspect you mean environments where firmware services are more under OS control. I certainly see a trend in that direction with technologies like the Android Virtualization Framework and Arm CCA, although I think there will always be some firmware the OS has to trust.
Regarding DICE, I’m seeing interest there too, although at the same time there is increasing prevalence of security processors in devices (not necessarily TPMs). If the security processor implements a DICE engine, it partially reduces the need for a highly layered measurement/attestation architecture. Anyway, I think this would be an excellent topic for a future TSC.
> There still seems to be a misconception about UEFI, that UEFI == EKD2
Yes, that’s a hard one to break!
> As you know Simon is proposing an alternative implementation called VBE…
Actually, I know very little about this – do you have any more information?
> 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.
Hmm, I thought they were already in contact but I can help make that happen if you want?
Regards
Dan.
From: Don Harbin <don.harbin@linaro.org>
Sent: 03 October 2022 14:57
To: tsc@lists.trustedfirmware.org
Cc: Joakim Bech <joakim.bech@linaro.org>; Dan Handley <Dan.Handley@arm.com>; Antonio De Angelis <Antonio.DeAngelis@arm.com>
Subject: Fwd: [Board] OSFC 2022
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@lists.trustedfirmware.org>
Date: Mon, 3 Oct 2022 at 01:20
Subject: [Board] OSFC 2022
To: <board@lists.trustedfirmware.org>, Okash Khawaja <okash@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-composition-engine/
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.
@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@lists.trustedfirmware.org
To unsubscribe send an email to board-leave@lists.trustedfirmware.org