Announcement: Introducing UEFI Capsule Update Integration for coreboot with EDK II
Hello, We are pleased to announce the launch of a project by 3mdeb aimed at integrating UEFI Capsule Update for coreboot with EDK II as a payload. This initiative aims to bring the capsule-based update method, providing an alternative to the traditional flashrom-based method, which becomes more and more difficult to implement, due to the restricted OS-level access to the firmware storage. One of the main goals is also to ease the integration and firmware update deployments via the fwupd for devices running open-source firmware (based on coreboot + EDK II). For a detailed project outline, please visit our Dasharo documentation [1]. We are looking for feedback through comments on this thread or via the built-in discussion module on the website. Although the project plan has been already accepted by the NLnet Foundation, there may be still some room for justified changes. You can track project's progress via the GitHub Project [2]. Your feedback and participation would be much appreciated. We welcome your involvement in discussions, reviewing, and testing. You might already have seen some first patches as a results of this project getting started, such us: - https://review.coreboot.org/c/coreboot/+/82247 - https://review.coreboot.org/c/coreboot/+/82248 - https://review.coreboot.org/c/coreboot/+/82249 - https://review.coreboot.org/c/coreboot/+/82610 We acknowledge and appreciate the funding support from the NLnet Foundation. [1] https://docs.dasharo.com/projects/capsule-updates/ [2] https://github.com/orgs/Dasharo/projects/7/views/1 Best regards, Beata Skierka Project Manager https://3mdeb.com | @3mdeb_com
Hi Beata, The [2] link does not work (Github 404). Chris On 7/11/24 13:17, Beata Skierka wrote:
Hello,
We are pleased to announce the launch of a project by 3mdeb aimed at integrating UEFI Capsule Update for coreboot with EDK II as a payload. This initiative aims to bring the capsule-based update method, providing an alternative to the traditional flashrom-based method, which becomes more and more difficult to implement, due to the restricted OS-level access to the firmware storage.
One of the main goals is also to ease the integration and firmware update deployments via the fwupd for devices running open-source firmware (based on coreboot + EDK II).
For a detailed project outline, please visit our Dasharo documentation [1]. We are looking for feedback through comments on this thread or via the built-in discussion module on the website. Although the project plan has been already accepted by the NLnet Foundation, there may be still some room for justified changes.
You can track project's progress via the GitHub Project [2].
Your feedback and participation would be much appreciated. We welcome your involvement in discussions, reviewing, and testing.
You might already have seen some first patches as a results of this project getting started, such us:
- https://review.coreboot.org/c/coreboot/+/82247 - https://review.coreboot.org/c/coreboot/+/82248 - https://review.coreboot.org/c/coreboot/+/82249 - https://review.coreboot.org/c/coreboot/+/82610
We acknowledge and appreciate the funding support from the NLnet Foundation.
[1] https://docs.dasharo.com/projects/capsule-updates/ [2] https://github.com/orgs/Dasharo/projects/7/views/1
Best regards, Beata Skierka Project Manager https://3mdeb.com | @3mdeb_com
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org -- *Christian Walter* *Head of Firmware Development / Cyber Security *
9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: christian.walter@9elements.com Phone: _+49 234 68 94 188 <tel:+492346894188>_ Mobile: _+49 176 70845047 <tel:+4917670845047>_ Sitz der Gesellschaft: Bochum Handelsregister: Amtsgericht Bochum, HRB 17519 Geschäftsführung: Sebastian Deutsch, Eray Basar Datenschutzhinweise nach Art. 13 DSGVO <https://9elements.com/privacy>
Hi Beata, Thanks for sharing that! It's great to see coreboot getting such features! Christian, link [2] works correctly for me in normal, logged-in and incognito sessions. Please check it again. Jakub On Thu, Jul 11, 2024 at 1:54 PM Christian Walter via coreboot < coreboot@coreboot.org> wrote:
Hi Beata,
The [2] link does not work (Github 404).
Chris On 7/11/24 13:17, Beata Skierka wrote:
Hello,
We are pleased to announce the launch of a project by 3mdeb aimed at integrating UEFI Capsule Update for coreboot with EDK II as a payload. This initiative aims to bring the capsule-based update method, providing an alternative to the traditional flashrom-based method, which becomes more and more difficult to implement, due to the restricted OS-level access to the firmware storage.
One of the main goals is also to ease the integration and firmware update deployments via the fwupd for devices running open-source firmware (based on coreboot + EDK II).
For a detailed project outline, please visit our Dasharo documentation [1]. We are looking for feedback through comments on this thread or via the built-in discussion module on the website. Although the project plan has been already accepted by the NLnet Foundation, there may be still some room for justified changes.
You can track project's progress via the GitHub Project [2].
Your feedback and participation would be much appreciated. We welcome your involvement in discussions, reviewing, and testing.
You might already have seen some first patches as a results of this project getting started, such us:
- https://review.coreboot.org/c/coreboot/+/82247 - https://review.coreboot.org/c/coreboot/+/82248 - https://review.coreboot.org/c/coreboot/+/82249 - https://review.coreboot.org/c/coreboot/+/82610
We acknowledge and appreciate the funding support from the NLnet Foundation.
[1] https://docs.dasharo.com/projects/capsule-updates/ [2] https://github.com/orgs/Dasharo/projects/7/views/1
Best regards, Beata Skierka Project Manager https://3mdeb.com | @3mdeb_com
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- *Christian Walter* *Head of Firmware Development / Cyber Security *
9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: christian.walter@9elements.com Phone: *+49 234 68 94 188 <+492346894188>* Mobile: *+49 176 70845047 <+4917670845047>*
Sitz der Gesellschaft: Bochum Handelsregister: Amtsgericht Bochum, HRB 17519 Geschäftsführung: Sebastian Deutsch, Eray Basar
Datenschutzhinweise nach Art. 13 DSGVO <https://9elements.com/privacy> _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Jakub, yup - works now :) Thanks! Chris On 7/11/24 14:22, Jakub Czapiga wrote:
Hi Beata,
Thanks for sharing that! It's great to see coreboot getting such features!
Christian, link [2] works correctly for me in normal, logged-in and incognito sessions. Please check it again.
Jakub
On Thu, Jul 11, 2024 at 1:54 PM Christian Walter via coreboot <coreboot@coreboot.org> wrote:
Hi Beata,
The [2] link does not work (Github 404).
Chris
On 7/11/24 13:17, Beata Skierka wrote:
Hello,
We are pleased to announce the launch of a project by 3mdeb aimed at integrating UEFI Capsule Update for coreboot with EDK II as a payload. This initiative aims to bring the capsule-based update method, providing an alternative to the traditional flashrom-based method, which becomes more and more difficult to implement, due to the restricted OS-level access to the firmware storage.
One of the main goals is also to ease the integration and firmware update deployments via the fwupd for devices running open-source firmware (based on coreboot + EDK II).
For a detailed project outline, please visit our Dasharo documentation [1]. We are looking for feedback through comments on this thread or via the built-in discussion module on the website. Although the project plan has been already accepted by the NLnet Foundation, there may be still some room for justified changes.
You can track project's progress via the GitHub Project [2].
Your feedback and participation would be much appreciated. We welcome your involvement in discussions, reviewing, and testing.
You might already have seen some first patches as a results of this project getting started, such us:
- https://review.coreboot.org/c/coreboot/+/82247 - https://review.coreboot.org/c/coreboot/+/82248 - https://review.coreboot.org/c/coreboot/+/82249 - https://review.coreboot.org/c/coreboot/+/82610
We acknowledge and appreciate the funding support from the NLnet Foundation.
[1] https://docs.dasharo.com/projects/capsule-updates/ [2] https://github.com/orgs/Dasharo/projects/7/views/1
Best regards, Beata Skierka Project Manager https://3mdeb.com | @3mdeb_com
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- *Christian Walter* *Head of Firmware Development / Cyber Security *
9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: christian.walter@9elements.com Phone: _+49 234 68 94 188 <tel:+492346894188>_ Mobile: _+49 176 70845047 <tel:+4917670845047>_
Sitz der Gesellschaft: Bochum Handelsregister: Amtsgericht Bochum, HRB 17519 Geschäftsführung: Sebastian Deutsch, Eray Basar
Datenschutzhinweise nach Art. 13 DSGVO <https://9elements.com/privacy> _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- *Christian Walter* *Head of Firmware Development / Cyber Security * 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: christian.walter@9elements.com Phone: _+49 234 68 94 188 <tel:+492346894188>_ Mobile: _+49 176 70845047 <tel:+4917670845047>_ Sitz der Gesellschaft: Bochum Handelsregister: Amtsgericht Bochum, HRB 17519 Geschäftsführung: Sebastian Deutsch, Eray Basar Datenschutzhinweise nach Art. 13 DSGVO <https://9elements.com/privacy>
Hi Beata, coreboot fellows, On 11.07.24 13:17, Beata Skierka wrote:
We are pleased to announce the launch of a project by 3mdeb aimed at integrating UEFI Capsule Update for coreboot with EDK II as a payload. This initiative aims to bring the capsule-based update method, providing an alternative to the traditional flashrom-based method, which becomes more and more difficult to implement, due to the restricted OS-level access to the firmware storage.
I wonder if this is the only incentive? Because it seems like an unfortunate myth :-/ You generally have these restrictions when using the user-space drivers. However, there are also kernel dri- vers and interfaces (e.g. `spi-intel` and the MTD interface in Linux). Flashrom and Flashprog both have a `linux_mtd` driver for this. So flash access shouldn't be a problem in general. Of course it needs to be secured, but that's independent of the way that gets the actual update to the program that writes it to the flash.
One of the main goals is also to ease the integration and firmware update deployments via the fwupd for devices running open-source firmware (based on coreboot + EDK II).
Is fwupd still Linux only? Because on Linux flashing should be ea- sier than in firmware. It may need some work on the kernel drivers but that's probably far, far less effort.
For a detailed project outline, please visit our Dasharo documentation [1].
This left me wondering: Where in the process are signatures verified? And which parts are signed? each chunk that is gathered from memory individually? or only the coalesced data? If it's the latter, we'd likely have a lot of code that is processing / influenced by untrusted input. Then I would strongly recommend not to implement it in C. SPARK would be the language of my choice. It integrates well with coreboot. Another thing that I didn't get yet: Why is coreboot involved? Couldn't edk2 gather the capsule chunks from memory? Best, Nico
Hi Nico,
On 11.07.24 13:17, Beata Skierka wrote:
We are pleased to announce the launch of a project by 3mdeb aimed at integrating UEFI Capsule Update for coreboot with EDK II as a payload. This initiative aims to bring the capsule-based update method, providing an alternative to the traditional flashrom-based method, which becomes more and more difficult to implement, due to the restricted OS-level access to the firmware storage. I wonder if this is the only incentive? Because it seems like an unfortunate myth :-/ You generally have these restrictions when using the user-space drivers. However, there are also kernel dri- vers and interfaces (e.g. `spi-intel` and the MTD interface in Linux). Flashrom and Flashprog both have a `linux_mtd` driver for this.
|Those drivers can't handle all of the protection mechanisms, for example SMM BWP (BIOS Write Protection) can only be disabled by a reset (bugs like broken S3 resume or misconfigured GPIO that would allow accessing the pins directly to bit-bang raw commands don't count).|
So flash access shouldn't be a problem in general. Of course it needs to be secured, but that's independent of the way that gets the actual update to the program that writes it to the flash.
One of the main goals is also to ease the integration and firmware update deployments via the fwupd for devices running open-source firmware (based on coreboot + EDK II). Is fwupd still Linux only? Because on Linux flashing should be ea- sier than in firmware. It may need some work on the kernel drivers but that's probably far, far less effort.
Just because the update is performed by firmware doesn't mean that the user has to interact with it directly. Flashing can be initialized from OS, but it can also be done by UEFI app in case of lack of support for capsules in OS. Yes, AFAICT fwupd is Linux only. However, this isn't the only software that uses capsules to perform the update, Windows also uses it (although this would require creating and distributing firmware as drivers through Windows Update, which is beyond the scope of this project). Linux can also be compiled with EFI_CAPSULE_LOADER [1] which exposes an interface for sending capsules to the firmware by a simple write to file. Can it really get easier than `cat firmware.bin > /dev/efi_capsule_loader` [2]?
For a detailed project outline, please visit our Dasharo documentation [1]. This left me wondering: Where in the process are signatures verified? And which parts are signed? each chunk that is gathered from memory individually? or only the coalesced data? If it's the latter, we'd likely have a lot of code that is processing / influenced by untrusted input. Then I would strongly recommend not to implement it in C. SPARK would be the language of my choice. It integrates well with coreboot.
Signatures are verified by edk2, on coalesced data. There are decisions made earlier based on presence of data, not on it's content. This is why we will take care to not allow booting an OS with full access to flash enabled when edk2 decides that the capsule isn't valid. I doubt that SPARK integrates with edk2 as nicely as it does with coreboot. That said, we don't have any professional SPARK / Ada developers in our team (at least nobody mentioned it), which leaves us with C.
Another thing that I didn't get yet: Why is coreboot involved? Couldn't edk2 gather the capsule chunks from memory?
Because it is coreboot that applies flash write protections, which must temporarily be lifted for edk2 to perform the update. coreboot also implements code for writing to flash (as an extension of SMMSTORE_V2), so edk2 doesn't even need to be aware of each chipset's unique way of interacting with the SPI controller. Capsule chunks are possibly written by the OS, after UEFI Boot Services are terminated and their memory regions potentially overwritten. This may include memory region to which coreboot loads the payload, so it must be aware of which regions to avoid. As it requires traversing through scatter-gather list anyway, copying the data to coalesced form at that point is easy, and it helps in avoiding accidentally overwriting capsules data when the payload is loaded. |[1] https://github.com/torvalds/linux/blob/v6.10/drivers/firmware/efi/Kconfig#L1... [2] https://lore.kernel.org/all/1454042394-21507-1-git-send-email-hock.leong.kweh@intel.com/T/| Best regards, Krystian -- Krystian Hebel Firmware Engineer https://3mdeb.com | @3mdeb_com
Hi Nico, Krystian. This feature sounds in general quite nice as it will improve the user experience for the firmware update scenario and align with the standard scenarios available out there nowadays. From the implementation point of view it looks a bit tricky to me: We do weave two independent projects (coreboot and Tianocore) quite a lot together in order to accomplish this task. Though there might be justifications to do that (coreboot owns SMM and unrestricted flash access can most complete be done from SMM while EDK II is the place to which the OS communicates to in order to provide the capsule), we should be careful doing so. There is just this one configuration out there which uses this feature (both sides, coreboot and Tianocore, need to enable capsule update). How shall be make sure that either side stays functional and will not logically break when the independent projects are getting developed further over the future? Do you plan to add any kind of unit test to both projects so that it can be guaranteed? Because I otherwise fear that this feature can break quite easy without being noticed by both communities on time. Is there a way forward to reduce the intersection between coreboot and Tianocore by limiting the task coreboot needs to serve, maybe to just temporarily disable the flash write protection? This way the update could be implemented mostly on Tianocore side reducing the dependencies a lot. Regards Werner
Hi Nico,
On 11.07.24 13:17, Beata Skierka wrote:
We are pleased to announce the launch of a project by 3mdeb aimed at integrating UEFI Capsule Update for coreboot with EDK II as a payload. This initiative aims to bring the capsule-based update method, providing an alternative to the traditional flashrom-based method, which becomes more and more difficult to implement, due to the restricted OS-level access to the firmware storage.
I wonder if this is the only incentive? Because it seems like an unfortunate myth :-/ You generally have these restrictions when using the user-space drivers. However, there are also kernel dri- vers and interfaces (e.g. `spi-intel` and the MTD interface in Linux). Flashrom and Flashprog both have a `linux_mtd` driver for this.
Those drivers can't handle all of the protection mechanisms, for example SMM BWP (BIOS Write Protection) can only be disabled by a reset (bugs like broken S3 resume or misconfigured GPIO that would allow accessing the pins directly to bit-bang raw commands don't count).
So flash access shouldn't be a problem in general. Of course it needs to be secured, but that's independent of the way that gets the actual update to the program that writes it to the flash.
One of the main goals is also to ease the integration and firmware update deployments via the fwupd for devices running open-source firmware (based on coreboot + EDK II).
Is fwupd still Linux only? Because on Linux flashing should be ea- sier than in firmware. It may need some work on the kernel drivers but that's probably far, far less effort. Just because the update is performed by firmware doesn't mean that the user has to interact with it directly. Flashing can be initialized from OS, but it can also be done by UEFI app in case of lack of support for capsules in OS.
Yes, AFAICT fwupd is Linux only. However, this isn't the only software that uses capsules to perform the update, Windows also uses it (although this would require creating and distributing firmware as drivers through Windows Update, which is beyond the scope of this project). Linux can also be compiled with EFI_CAPSULE_LOADER [1] which exposes an interface for sending capsules to the firmware by a simple write to file. Can it really get easier than `cat firmware.bin > /dev/efi_capsule_loader` [2]?
For a detailed project outline, please visit our Dasharo documentation [1].
This left me wondering: Where in the process are signatures verified? And which parts are signed? each chunk that is gathered from memory individually? or only the coalesced data? If it's the latter, we'd likely have a lot of code that is processing / influenced by untrusted input. Then I would strongly recommend not to implement it in C. SPARK would be the language of my choice. It integrates well with coreboot.
Signatures are verified by edk2, on coalesced data. There are decisions made earlier based on presence of data, not on it's content. This is why we will take care to not allow booting an OS with full access to flash enabled when edk2 decides that the capsule isn't valid.
I doubt that SPARK integrates with edk2 as nicely as it does with coreboot. That said, we don't have any professional SPARK / Ada developers in our team (at least nobody mentioned it), which leaves us with C. Another thing that I didn't get yet: Why is coreboot involved? Couldn't edk2 gather the capsule chunks from memory? Because it is coreboot that applies flash write protections, which must temporarily be lifted for edk2 to perform the update. coreboot also implements code for writing to flash (as an extension of SMMSTORE_V2), so edk2 doesn't even need to be aware of each chipset's unique way of interacting with the SPI controller.
Capsule chunks are possibly written by the OS, after UEFI Boot Services are terminated and their memory regions potentially overwritten. This may include memory region to which coreboot loads the payload, so it must be aware of which regions to avoid. As it requires traversing through scatter-gather list anyway, copying the data to coalesced form at that point is easy, and it helps in avoiding accidentally overwriting capsules data when the payload is loaded. [1] https://github.com/torvalds/linux/blob/v6.10/drivers/firmware/efi/Kconfig#L1 24 [2] https://lore.kernel.org/all/1454042394-21507-1-git-send-email-hock.leong.kwe h@intel.com/T/ Best regards, Krystian
Hi Werner, On Fri, Sep 06, 2024 at 01:10:54PM +0000, Zeh, Werner wrote:
From the implementation point of view it looks a bit tricky to me: We do weave two independent projects (coreboot and Tianocore) quite a lot together in order to accomplish this task. Though there might be justifications to do that (coreboot owns SMM and unrestricted flash access can most complete be done from SMM while EDK II is the place to which the OS communicates to in order to provide the capsule), we should be careful doing so. There is just this one configuration out there which uses this feature (both sides, coreboot and Tianocore, need to enable capsule update). How shall be make sure that either side stays functional and will not logically break when the independent projects are getting developed further over the future?
The situation is similar to the one with SMMSTORE: coreboot configuration that wants to support capsules should use an appropriate EDK2 fork and revision even after things get fully upstreamed. coreboot is also the one responsible for specifying package and defines/PCDs for EDK2 and thus ultimately dictates whether the feature is enabled in the firmware as a whole.
Do you plan to add any kind of unit test to both projects so that it can be guaranteed? Because I otherwise fear that this feature can break quite easy without being noticed by both communities on time.
Automated tests are available at https://github.com/Dasharo/open-source-firmware-validation/blob/a6414a7e3a23... They can be run in QEMU or on real hardware (requires appropriate setup). This doesn't test upstream coreboot, but once changes are upstreamed and Dasharo fork is rebased, it essentially will.
Is there a way forward to reduce the intersection between coreboot and Tianocore by limiting the task coreboot needs to serve, maybe to just temporarily disable the flash write protection? This way the update could be implemented mostly on Tianocore side reducing the dependencies a lot.
The point of using SMMSTORE was to avoid reimplementing flash driver in EDK2 and just use the existing one in coreboot. Most of the code added to coreboot is related to gathering pieces of capsules scattered almost anywhere in RAM by an OS before warm reset. coreboot either needs to do this or be very careful to avoid stepping on all of those regions and hope that none of them will create problems for starting payload. coreboot then provides list of capsules in CBMEM. All the actual processing is in EDK2, only the most low-level part is handled by coreboot which in EDK2-only firmware is done by its PEI part. Regards, Sergii
Hi Krystian, Nico, On Wed, Aug 14, 2024 at 05:22:54PM +0200, Krystian Hebel wrote:
Is fwupd still Linux only? [...]
[...] Yes, AFAICT fwupd is Linux only.
Even the oldest release on GitHub (Feb 3, 2020) has fwupd-1.3.7-setup-x86_64.exe: https://github.com/fwupd/fwupd/releases/tag/1.3.7 And don't forget about bringing fwupd to BSD-systems: https://nlnet.nl/project/fwdup-BSD/ Regards, Sergii
Hi Krystian & Sergii, thanks for your input and sorry for the long silence on my end. I see this discussion taking a shape that I'm too familiar with: A solution is discussed before the requirements are stated. I know these capsule updates solve a real problem. But just like any patch that "works" that doesn't imply it's a good design for upstream, or the way our ecosystem should take in the long run. So before discussing your solution, I'd like to make one attempt to blow your minds. On 14.08.24 17:22, Krystian Hebel wrote:
[...] Linux can also be compiled with EFI_CAPSULE_LOADER [1] which exposes an interface for sending capsules to the firmware by a simple write to file. Can it really get easier than `cat firmware.bin > /dev/efi_capsule_loader` [2]?
Yes! much easier: `cp firmware.bin /boot/efi/update/` :-))) 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). I believe not just for coreboot, but for the overall ecosystem, the capsule-update mechanism looks like an unnecessary, way too complex alien. As many things, it is accepted for compatibility with proprietary firmware. :-( So, what I'm suggesting is to just look for an update in a pre- defined path on the boot medium. This could be a 20-line patch to the Boot Loader Specification. The file format and authenti- cation would be implementation specific. Which is IMO the only right thing to specify in this case, because the file contents are firmware _and_ device specific anyway. I believe a simple specification like this could strengthen our ecosystem. Also, this would allow a much simpler implementation for your edk2 payload that is easier to secure. Finding a file, verifying it like any other file, and flashing that. Whether to use an SMI handler for the latter or not could be discussed se- parately[4]. WDYT? Best, Nico
[2] https://lore.kernel.org/all/1454042394-21507-1-git-send-email-hock.leong.kwe...
[3] https://uapi-group.org/specifications/specs/boot_loader_specification/ [4] I've just put "uefi libc" into my browser and saw edk2-libc. Shouldn't be hard to link something like (lib)flashprog with it. We already do that with libpayload. Flashing in the pay- load should be covered and seems much more reasonable to me.
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] So why is the fragile, more complex, harder to secure memory-scatter- gather-mix-coreboot-with-edk2 path even considered? What do I miss? Nico [1] https://uefi.org/specs/UEFI/2.10_A/08_Services_Runtime_Services.html#deliver...
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]
And there is a fwupd plugin supporting it[2].
So why is the fragile, more complex, harder to secure memory-scatter- gather-mix-coreboot-with-edk2 path even considered? What do I miss?
Nico
[1] https://uefi.org/specs/UEFI/2.10_A/08_Services_Runtime_Services.html#deliver...
[2] https://fwupd.github.io/libfwupdplugin/uefi-capsule-README.html#update-behav...
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
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
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
Hi Nico,
Hi Krystian & Sergii,
thanks for your input and sorry for the long silence on my end.
I see this discussion taking a shape that I'm too familiar with: A solution is discussed before the requirements are stated. I know these capsule updates solve a real problem. But just like any patch that "works" that doesn't imply it's a good design for upstream, or the way our ecosystem should take in the long run.
So before discussing your solution, I'd like to make one attempt to blow your minds.
On 14.08.24 17:22, Krystian Hebel wrote:
[...] Linux can also be compiled with EFI_CAPSULE_LOADER [1] which exposes an interface for sending capsules to the firmware by a simple write to file. Can it really get easier than `cat firmware.bin > /dev/efi_capsule_loader` [2]? Yes! much easier: `cp firmware.bin /boot/efi/update/` :-)))
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).
I believe not just for coreboot, but for the overall ecosystem, the capsule-update mechanism looks like an unnecessary, way too complex alien. As many things, it is accepted for compatibility with proprietary firmware. :-(
So, what I'm suggesting is to just look for an update in a pre- defined path on the boot medium. This could be a 20-line patch to the Boot Loader Specification. The file format and authenti- cation would be implementation specific. Which is IMO the only right thing to specify in this case, because the file contents are firmware _and_ device specific anyway.
I believe a simple specification like this could strengthen our ecosystem. Also, this would allow a much simpler implementation for your edk2 payload that is easier to secure. Finding a file, verifying it like any other file, and flashing that. Whether to use an SMI handler for the latter or not could be discussed se- parately.
WDYT?
This is something we were considering. The problem with that approach is that coreboot can (and, in most of platforms supported by us, does) lock the boot medium, either by mechanism implemented by src/security/lockdown, or SMM BWP, or both. The payload isn't able to remove those locks, they wouldn't be of much use if it could. The only option is to not set them in the first place, which means that coreboot must be aware of existence of update, whatever it's form may be. Dealing with in-memory capsules is much easier than adding storage and filesystem drivers to coreboot, not to mention that this would be against its design philosophy. I completely understand the hesitance against adding more code to resident callbacks. We may consider moving the code for flashing to edk2, but unless the responsibility for properly locking SMM and flash access is also part of the payload, coreboot can't be left out of the picture. Krystian Hebel Firmware Engineer https://3mdeb.com | @3mdeb_com
Hi Krystian, On 14.09.24 00:03, Krystian Hebel wrote:
So, what I'm suggesting is to just look for an update in a pre- defined path on the boot medium. [...]
This is something we were considering. The problem with that approach is that coreboot can (and, in most of platforms supported by us, does) lock the boot medium, either by mechanism implemented by src/security/lockdown, or SMM BWP, or both. The payload isn't able to remove those locks, they wouldn't be of much use if it could.
Um no, not coreboot. coreboot is free software and if it would do something that hinders security, we would fix it. Judging by the terms you are using, I assume this is about Intel FSP. FSP does lock things, sometimes too early, sometimes even in an insecure state (i.e. locking empty protection registers). I don't think we should allow Intel's insecurity to have such an influence on coreboot designs, rather we should contain it as much as possible, i.e. try to find solutions that are as close as possible to what we would do in a nicer world without FSP.
The only option is to not set them in the first place, which means that coreboot must be aware of existence of update, whatever it's form may be. Dealing with in-memory capsules is much easier than adding storage and filesystem drivers to coreboot, not to mention that this would be against its design philosophy.
You're mixing things that shouldn't be mixed, IMO. Absolutely yes, of course dealing with memory structures is easier than dealing with storage *in coreboot*. But we shouldn't do any such data processing *in coreboot*, anyway. What coreboot re- quires is only the control over the locking. And there *are* alternatives. tl;dr this is what we came up with @secunet when Intel FSP was pushed into mainstream coreboot: We use an nvram flag to tell coreboot to lock or not[1]. The payload then has to live with what it gets: locked => don't update, unlocked => don't boot. Nico [1] https://review.coreboot.org/c/coreboot/+/56344/
Hi Nico, On 9/14/24 2:29 PM, Nico Huber wrote:
Hi Krystian,
On 14.09.24 00:03, Krystian Hebel wrote:
So, what I'm suggesting is to just look for an update in a pre- defined path on the boot medium. [...] This is something we were considering. The problem with that approach is that coreboot can (and, in most of platforms supported by us, does) lock the boot medium, either by mechanism implemented by src/security/lockdown, or SMM BWP, or both. The payload isn't able to remove those locks, they wouldn't be of much use if it could. Um no, not coreboot. coreboot is free software and if it would do something that hinders security, we would fix it. Judging by the terms you are using, I assume this is about Intel FSP. FSP does lock things, sometimes too early, sometimes even in an insecure state (i.e. locking empty protection registers). I don't think we should allow Intel's insecurity to have such an influence on coreboot designs, rather we should contain it as much as possible, i.e. try to find solutions that are as close as possible to what we would do in a nicer world without FSP.
No, it is coreboot I'm talking about. Unless CONFIG_BOOTMEDIA_LOCK_NONE is selected, the call trace is as following: boot_device_security_lockdown(), called by boot state machine [1] boot_device_wp_region(), if there are any RO regions [2] spi_flash_set_write_protected() [3] appropriate prot_ops->set_write() [4] set_write() interacts with SPI flash directly [5] In case of SMM BWP, this is also set by coreboot [6]. FSP isn't involved anywhere in these processes. [1] https://github.com/coreboot/coreboot/blob/c512585e55d3ba998c9e2b6ffc6899642e... [2] https://github.com/coreboot/coreboot/blob/c512585e55d3ba998c9e2b6ffc6899642e... [3] https://github.com/coreboot/coreboot/blob/c512585e55d3ba998c9e2b6ffc6899642e... [4] https://github.com/coreboot/coreboot/blob/c512585e55d3ba998c9e2b6ffc6899642e... [5] https://github.com/coreboot/coreboot/blob/c512585e55d3ba998c9e2b6ffc6899642e... [6] https://github.com/coreboot/coreboot/blob/c512585e55d3ba998c9e2b6ffc6899642e...
The only option is to not set them in the first place, which means that coreboot must be aware of existence of update, whatever it's form may be. Dealing with in-memory capsules is much easier than adding storage and filesystem drivers to coreboot, not to mention that this would be against its design philosophy. You're mixing things that shouldn't be mixed, IMO. Absolutely yes, of course dealing with memory structures is easier than dealing with storage *in coreboot*. But we shouldn't do any such data processing *in coreboot*, anyway. What coreboot re- quires is only the control over the locking. And there *are* alternatives.
What coreboot requires is control over the locking *and* knowledge about which regions of memory to avoid, e.g. when loading the payload or preparing data for it. Basically all of the code that isn't part of S3 resume path is free to overwrite memory that isn't otherwise reserved. Unfortunately, this means parsing of scatter-gather lists, we weren't able to find a way around it.
tl;dr this is what we came up with @secunet when Intel FSP was pushed into mainstream coreboot: We use an nvram flag to tell coreboot to lock or not[1]. The payload then has to live with what it gets: locked => don't update, unlocked => don't boot.
This is similar to what we've done, except instead of using coreboot options API, we're making the decision based on UEFI variables related to capsules, which are read anyway to locate the capsule data. I'm curious, though, have you found a way to enforce "don't boot" part without depending on payload's good behavior? -- Krystian Hebel Firmware Engineer https://3mdeb.com | @3mdeb_com
Hi Krystian, On 17.09.24 19:42, Krystian Hebel wrote:
On 9/14/24 2:29 PM, Nico Huber wrote:
On 14.09.24 00:03, Krystian Hebel wrote:
So, what I'm suggesting is to just look for an update in a pre- defined path on the boot medium. [...] This is something we were considering. The problem with that approach is that coreboot can (and, in most of platforms supported by us, does) lock the boot medium, either by mechanism implemented by src/security/lockdown, or SMM BWP, or both. The payload isn't able to remove those locks, they wouldn't be of much use if it could. Um no, not coreboot. coreboot is free software and if it would do something that hinders security, we would fix it. Judging by the terms you are using, I assume this is about Intel FSP. FSP does lock things, sometimes too early, sometimes even in an insecure state (i.e. locking empty protection registers). I don't think we should allow Intel's insecurity to have such an influence on coreboot designs, rather we should contain it as much as possible, i.e. try to find solutions that are as close as possible to what we would do in a nicer world without FSP.
No, it is coreboot I'm talking about. Unless CONFIG_BOOTMEDIA_LOCK_NONE is selected, the call trace is as following: boot_device_security_lockdown(), called by boot state machine [1] boot_device_wp_region(), if there are any RO regions [2] spi_flash_set_write_protected() [3] appropriate prot_ops->set_write() [4] set_write() interacts with SPI flash directly [5] In case of SMM BWP, this is also set by coreboot [6]. FSP isn't involved anywhere in these processes. [1] https://github.com/coreboot/coreboot/blob/c512585e55d3ba998c9e2b6ffc6899642e... [2] https://github.com/coreboot/coreboot/blob/c512585e55d3ba998c9e2b6ffc6899642e... [3] https://github.com/coreboot/coreboot/blob/c512585e55d3ba998c9e2b6ffc6899642e... [4] https://github.com/coreboot/coreboot/blob/c512585e55d3ba998c9e2b6ffc6899642e... [5] https://github.com/coreboot/coreboot/blob/c512585e55d3ba998c9e2b6ffc6899642e... [6] https://github.com/coreboot/coreboot/blob/c512585e55d3ba998c9e2b6ffc6899642e...
Um yes, but it's all configurable, isn't it? What I miss is why you'd choose a configuration that doesn't allow you to keep your security model simple, i.e. if that is what is demanding to take the SG solution. Reading below I guess it's that you don't trust edk2 to always do the right thing on a (less locked down) update path?
The only option is to not set them in the first place, which means that coreboot must be aware of existence of update, whatever it's form may be. Dealing with in-memory capsules is much easier than adding storage and filesystem drivers to coreboot, not to mention that this would be against its design philosophy. You're mixing things that shouldn't be mixed, IMO. Absolutely yes, of course dealing with memory structures is easier than dealing with storage *in coreboot*. But we shouldn't do any such data processing *in coreboot*, anyway. What coreboot re- quires is only the control over the locking. And there *are* alternatives.
What coreboot requires is control over the locking *and* knowledge about which regions of memory to avoid,
If you want the SG solution, yes. But I think that's where we are talking past each other. To me this seem like making the solution a requirement.
e.g. when loading the payload or preparing data for it. Basically all of the code that isn't part of S3 resume path is free to overwrite memory that isn't otherwise reserved. Unfortunately, this means parsing of scatter-gather lists, we weren't able to find a way around it.
tl;dr this is what we came up with @secunet when Intel FSP was pushed into mainstream coreboot: We use an nvram flag to tell coreboot to lock or not[1]. The payload then has to live with what it gets: locked => don't update, unlocked => don't boot.
This is similar to what we've done, except instead of using coreboot options API, we're making the decision based on UEFI variables related to capsules, which are read anyway to locate the capsule data. I'm curious, though, have you found a way to enforce "don't boot" part without depending on payload's good behavior?
No, we haven't. But we come from different worlds. For us, the payload is simple and controllable and coreboot is the too com- plex, hard to control beast (multiple exit points, boot-state hooks, dependence on too many variables...and ofc. FSP). So we trust the payload more than coreboot when it comes to security locks. The only reason for us to get coreboot involved with the flash security was that many FSP binaries lock things that they shouldn't. Nico
participants (8)
-
Arthur Heymans -
Beata Skierka -
Christian Walter -
Jakub Czapiga -
Krystian Hebel -
Nico Huber -
Sergii Dmytruk -
Zeh, Werner