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?