Attention is currently required from: Benjamin Doron, Nico Huber.
Patrick Georgi 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:
(2 comments)
File Documentation/drivers/smmstore.md:
https://review.coreboot.org/c/coreboot/+/79095/comment/ea19c22b_68a0e94a : PS2, Line 171: An attacker could mess with future calls into the APIs, but they : can already do so: Other common APIs for boot level variable are : implemented in RAM as well, so they can easily be defused.
nit: variables? Also, are you thinking of coreboot CMOS or UEFI variables here? Or both, I suppose. […]
The attack vector is overwriting the UEFI entry point to the variable functions which isn't in SMM but in RAM: the modified-UEFI could then pretend to do whatever variable updates were requested that it doesn't want to see done (e.g. installing a blocklist), and even cache the data for the current run to return "good" values, but never actually write it down.
In terms of UEFI Secure Boot: suppose some malicious boot level code is accidentally signed with a valid key, and the system wants to push a dbx update to block that malicious code from being accepted. On systems where that code already runs, to ensure its own persistence across boots it could intercept SetVariable and GetVariable and pretend that dbx is updated when it isn't.
But yes, I need to see how to put that in the doc more clearly, so thanks for the feedback.
https://review.coreboot.org/c/coreboot/+/79095/comment/b116b201_9de6c630 : PS2, Line 177: As a remedy, CLEAR could be disabled after the initial repacking, : within the boot process, so that SMMSTORE becomes an append-only : store. In this case, the attacker could fill up the buffer, leading : to a DoS of the variable store until it's repacked. As described : earlier, once there's an attacker on the system, the variable store : lost its function until the attacker has been evicted, anyway.
Raw WRITE has to be protected to, because writing 0xFF is equivalent to clearing. […]
Raw write from outside SMM is supposed to be disabled in the SMMSTORE model, yes. I'll make that clearer. SMM is used to ensure that the flash region becomes append-only (except for CLEAR)