Hi Nico,
Hi Krystian & Sergii,
thanks for your input and sorry for the long silence on my end.
I see this discussion taking a shape that I'm too familiar with: A solution is discussed before the requirements are stated. I know these capsule updates solve a real problem. But just like any patch that "works" that doesn't imply it's a good design for upstream, or the way our ecosystem should take in the long run.
So before discussing your solution, I'd like to make one attempt to blow your minds.
On 14.08.24 17:22, Krystian Hebel wrote:
[...] Linux can also be compiled with EFI_CAPSULE_LOADER [1] which exposes an interface for sending capsules to the firmware by a simple write to file. Can it really get easier than `cat firmware.bin > /dev/efi_capsule_loader` [2]?
Yes! much easier: `cp firmware.bin /boot/efi/update/` :-)))
No EFI_CAPSULE_LOADER needed, not Linux specific. EFI-aware OS' are also aware of the EFI system partition, FWIW. And with the Boot Loader Specification[3], we already try to make use of it beyond UEFI.
Modeling things with files is a good choice by the Linux kernel developers. But the overall design seems to miss that the boot- loaders are file-aware too! We already have a ubiquitous mecha- nism to pass files (usually the kernel) to the firmware. Often also to validate their authenticity (secure boot).
I believe not just for coreboot, but for the overall ecosystem, the capsule-update mechanism looks like an unnecessary, way too complex alien. As many things, it is accepted for compatibility with proprietary firmware. :-(
So, what I'm suggesting is to just look for an update in a pre- defined path on the boot medium. This could be a 20-line patch to the Boot Loader Specification. The file format and authenti- cation would be implementation specific. Which is IMO the only right thing to specify in this case, because the file contents are firmware _and_ device specific anyway.
I believe a simple specification like this could strengthen our ecosystem. Also, this would allow a much simpler implementation for your edk2 payload that is easier to secure. Finding a file, verifying it like any other file, and flashing that. Whether to use an SMI handler for the latter or not could be discussed se- parately.
WDYT?
This is something we were considering. The problem with that approach is that coreboot can (and, in most of platforms supported by us, does) lock the boot medium, either by mechanism implemented by src/security/lockdown, or SMM BWP, or both. The payload isn't able to remove those locks, they wouldn't be of much use if it could.
The only option is to not set them in the first place, which means that coreboot must be aware of existence of update, whatever it's form may be. Dealing with in-memory capsules is much easier than adding storage and filesystem drivers to coreboot, not to mention that this would be against its design philosophy.
I completely understand the hesitance against adding more code to resident callbacks. We may consider moving the code for flashing to edk2, but unless the responsibility for properly locking SMM and flash access is also part of the payload, coreboot can't be left out of the picture.
Krystian Hebel Firmware Engineer https://3mdeb.com | @3mdeb_com