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