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[4]. WDYT? Best, Nico > > [2] > https://lore.kernel.org/all/1454042394-21507-1-git-send-email-hock.leong.k...@intel.com/T/ [3] https://uapi-group.org/specifications/specs/boot_loader_specification/ [4] I've just put "uefi libc" into my browser and saw edk2-libc. Shouldn't be hard to link something like (lib)flashprog with it. We already do that with libpayload. Flashing in the pay- load should be covered and seems much more reasonable to me. _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
