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#delivery-of-capsules-via-file-on-mass-storage-device Regards, Sergii _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
