Re: Announcement: Introducing UEFI Capsule Update Integration for coreboot with EDK II

Arthur Heymans <[email protected]>
Newsgroups gmane.linux.bios
Message-ID <CAMLB0fcvcidpVcRUyg-0Cd1sUWwgg79Y9RM_dYPPivKv-EKKWA@mail.gmail.com>
>
> 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

_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.