[M] Change in coreboot[main]: Documentation: Describe how SMMSTORE can be used safely

[Benjamin Doron (Code Review)]

Attention is currently required from: Patrick Georgi.

Benjamin Doron has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/79095?usp=email )

Change subject: Documentation: Describe how SMMSTORE can be used safely
......................................................................

Patch Set 2:

(1 comment)

Patchset:

PS2:
> Looks pretty good to me. From "the boot process ... […]

I've thought more about a possible LOCK command, and I don't think it works for secure boot unfortunately.

UEFI variable stores are always append-only. When overwriting, it invalidates the old one and writes a new one. So just switching to append-only isn't an option.

We also can't select a range to protect, that would probably contain other variables, some are very prone to move. It would have to be a list of ranges (UEFI code would probably have to search by hand *and* consider fault-tolerance. I'm not looking forward to that).

But still: when to lock? DxeReadyToLock is an idea, before untrusted code can run. Or one of the end-of-firmware events. But the problem is, the user and OS only gets to customise secure boot *after* ready-to-lock. UEFI's model allows this: a physically present user is authorised in the setup menu, and the OS can update if the update is signed by existing keys.