Hi Jan, Francois:
Grant: thanks!
From: Jan Kiszka jan.kiszka@siemens.com On 24.04.19 03:23, daniel.sangorrin@toshiba.co.jp wrote:
Hello Francois, Jan, Christian, and all EFI Boot Guard is now shipped in quite a few devices, to my knowledge not only at Sorry for the late reply, I was waiting for the administrator of the Boot Architecture mailing list to accept my
subscription request, but it seems it will take a bit more time. I will send this reply and hope it will not be blocked. I have also added the u-boot mailing list to Cc, as Tom suggested (although I'm not a member), the CIP mailing list, Jan Kiszka (one of the main developers of Efibootguard) and Christian (an expert in software updates).
Background: during the last Linaro connect in Bangkok I was told that Linaro Edge (LEDGE) were working on
a secure software update mechanism based on UEFI capsules that would flash firmware updates from a UEFI application, instead of using a Linux agent such as SWUpdate.
How would capsules help with writing to arbitrary storage, updating only files on filesystem, reducing the update size (binary diffs), or talking to the cloud?
- arbitrary storage: I guess they can only write to what is supported by the machine's UEFI implementation. - updating only files on filesystem: I assume this is out of scope in their architecture (Francois: do you want to support file-based updates or only block-based ones?) - reducing the update size (binary diffs), or talking to the cloud: they will do that from non-secure Linux. It would be dangerous to use a fragile network stack from an UEFI application or the secure world. In that sense, they also need a Linux agent.
I believe that LEDGE is looking for a software update method that works the same on any machine (that supports UEFI). To do that they want to use the UEFI interfaces/services. They also want the ability to update the TrustZone secure world (you can't do that unless you have enough privileges).
As far as I know, there is no concept of "Secure Booting" in Efibootguard at the moment. Adding signature
checks before booting into the selected kernel would be a possible solution.
Secure boot is a pending feature on our to-do list. It's a bit more complicated than that, like secure boot is "a bit" more complicated than you think once you actually try to implement it. Once we do that, it's really about adding signature checks or relying on UEFI validating the payloads we boot for us PLUS ensuring the our config sections can either be validated (despite being volatile) or split the security-wise critical parts (specifically EFI payload parameters) from the less critical ones (update states) and remove the latter from the validation.
I suppose that those "bits" are hard to predict until you start the implementation. From an architectural point of view, I guess that the "revision" variables will need to be secured to avoid downgrades (e.g. an attacker causing a rollback to a previous revision of the OS image).
BTW, what we do in EFI Board Guard could also be done in any other UEFI bootloader, may it be grub (if you like to use that complex and fragile beast in production), systemd-boot or even TianoCore. But for now, it was easier - and more robust - to add our requirements in form of this tiny bootloader to the ecosystem. EFI Boot Guard is now shipped in quite a few devices, to my best knowledge not only at Siemens.
Jan: do you have a schedule or a list of tasks that need to be done? Francois: what direction should we take from here?
Thanks, Daniel