On Fri, Sep 13, 2024 at 02:07:54PM +0200, Nico Huber wrote:
On 13.09.24 13:51, Nico Huber via coreboot wrote:
On 13.09.24 13:07, Nico Huber via coreboot wrote:
So, what I'm suggesting is to just look for an update in a pre- defined path on the boot medium.
Looks like this is already specified for capsules:
8.5.5. Delivery of Capsules via file on Mass Storage Device[1]
Yes, what you're proposing is essentially the same as on-disk capsules. EDK2 "implements" them (the implementation looks broken in several ways) by loading a capsule into memory and doing a soft reset. That could have played a role in choosing in-RAM capsules.
So why is the fragile, more complex, harder to secure memory-scatter- gather-mix-coreboot-with-edk2 path even considered? What do I miss?
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
My judgement might also be influenced by not seeing anything wrong in making coreboot do part of the job for a more feature-full payload when it replaces part of its functionality.
Nico
[1] https://uefi.org/specs/UEFI/2.10_A/08_Services_Runtime_Services.html#deliver...
Regards, Sergii