Hi Sergii, Arthur,
On 13.09.24 16:43, Arthur Heymans wrote:
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.
I don't know how UEFI models network boot. But assuming that it's also something like a "mounted" FS, it might work too?
If not doing EFI, one could ofc. define their own way to retrieve updates.
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
I don't think this is bad? Considering more than Linux, I think it's actually better than having to implement things inside the kernel.
- 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?
It says the firmware should remove the file, however then states that it may silently fail doing so :) I would also prefer to not let the firmware write to file systems.
Nico