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
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
