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