Patrick Georgi has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/79095?usp=email )
Change subject: Documentation: Describe how SMMSTORE can be used safely ......................................................................
Documentation: Describe how SMMSTORE can be used safely
SMMSTORE is designed as a secure, minimal primitive with which more complex constructs can be designed. Apparently I never wrote down the details, so fix that issue.
Change-Id: I48f44d3416d210e1e6b19d18cad787e380ffeebc Signed-off-by: Patrick Georgi patrick@coreboot.org --- M Documentation/drivers/smmstore.md 1 file changed, 66 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/95/79095/1
diff --git a/Documentation/drivers/smmstore.md b/Documentation/drivers/smmstore.md index 7082747..22b7b4b 100644 --- a/Documentation/drivers/smmstore.md +++ b/Documentation/drivers/smmstore.md @@ -126,6 +126,72 @@ DRAM. A malicious application that is able to issue SMIs could extract arbitrary data or modify the currently running kernel.*
+## Design rationale / Implementation advice + +The SMMSTORE driver doesn't offer any validation, it simply writes data +to a limited region of flash. It still serves as a useful primitive +with which systems (payloads, operating systems, ...) can implement an +optionally-authenticated variable store. + +The boot process up to the initial processing of the variable store by +the data store's consumer (not just coreboot) needs to be trusted to retain +trust in the data store as a whole. + +With that: + +- coreboot initializes the SMMSTORE driver +- The consumer initializes its use of the driver, by + - reading the store into its own memory; + - while doing so, process authentication data and reject invalid blocks; + - Ideally the consumer at this point compacts the store if it's useful + to do so (i.e. the resulting set of updated-and-authenticated data + is much smaller than what was read from the store) +- During general operation, the store isn't normally exposed directly to + clients. For example with UEFI + Windows, UEFI would provide its API + for variable manipulation and use SMMSTORE in the backend, while Windows + doesn't need to care about the format and just uses UEFI services. +- Such services can do preliminary processing on update-time, updating + the in-RAM variable set and SMMSTORE at the same time, if and only + if the requested update satisfies its criteria. It could also decide + to just accept any update for the time being, moving verification + into the more secure boot process (where there isn't an OS plus + who-knows-how-many processes potentially observing CPU state). + Some care needs to be taken that these data updates aren't trusted + before the next reset, though. +- Direct access to SMM is possible from privileged mode, which could + be used to bypass any authentication once an attacker entered privileged + mode. For non-authenticated data this makes no difference: an attacker + could just as well use the regular interface to write whatever data + they want to write. + + The authenticated case needs a closer look: + - An attacker could store arbitrary data in SMMSTORE, but that is not a + problem if the data is validated during the boot process (as + required above) + - 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. + - An attacker could flush the store with the CLEAR command. This is a + potential problem if the "empty state" is somehow less secure than + a fully configured system. + - 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. + + Such an approach "only" needs to ensure that regular operation doesn't + typically run into buffer limits, and the user of the public API + needs to handle error conditions properly (it better does, anyway). + +Such a design minimizes the amount of logic in SMM, which is a security +critical mode. It can also help minimize the exposure of security code +(e.g. key validation for authenticated variables) while lots of different +programs are running on the same system, for example by deferring _all_ +authenticated variable checking to the next boot, which is (hopefully) +a less crowded environment for crypto code to do its work unsupervised. + ## External links
* [A Tour Beyond BIOS Implementing UEFI Authenticated Variables in SMM with EDKI](https://software.intel.com/sites/default/files/managed/cf/ea/a_tour_beyond_b...)