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).
So basically instead of a runtime service, getting a file from a disk at boottime to update the flash? I think this is indeed dramatically simpler on both the firmware side as the OS side. I suppose this only works when there is a boot disk, but then again servers tend to have a BMC which takes care of firmware updates anyway. So this seems like a good trade-off.
Not sure about exact considerations which went into the decision other than
on-disk capsules already working in EDK2, but use of in-RAM capsules looks like a cleaner design to me:
- no file-system writes by an OS
- no file-system writes by firmware to remove a processed capsule (not sure I want to trust EDK2 drivers doing that)
- the capsule can be verified at the moment it's offered to the firmware, not in the middle of a boot
- File system writes are way simpler than supporting an UEFI runtime service. - Does the firmware need to remove the capsule? Can't fwupd do that once it detects a successful update? What does the spec say about this? - Doing things at runtime is against the coreboot philosophy. If doing something at boottime is a reasonable option to avoid needing a runtime I think this is the way to go.
I generally like Nico's proposal. No new coreboot-payload interaction (depends on the design). Less runtime. Reusing existing spec and tooling. This is the way to go in my opinion.
Arthur