Martin Roth has submitted this change and it was merged. ( https://review.coreboot.org/19242 )
Change subject: Documentation: Add technote/design doc for mitigating ReBAR issue ......................................................................
Documentation: Add technote/design doc for mitigating ReBAR issue
Change-Id: Icba9d7910dfd46f32a2c46b6fd064a9cc8e3beac Signed-off-by: Patrick Georgi pgeorgi@chromium.org Reviewed-on: https://review.coreboot.org/19242 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer stefan.reinauer@coreboot.org --- A Documentation/technotes/2017-02-dealing-with-untrusted-input-in-smm.md 1 file changed, 136 insertions(+), 0 deletions(-)
Approvals: Stefan Reinauer: Looks good to me, approved build bot (Jenkins): Verified
diff --git a/Documentation/technotes/2017-02-dealing-with-untrusted-input-in-smm.md b/Documentation/technotes/2017-02-dealing-with-untrusted-input-in-smm.md new file mode 100644 index 0000000..ce1a097 --- /dev/null +++ b/Documentation/technotes/2017-02-dealing-with-untrusted-input-in-smm.md @@ -0,0 +1,136 @@ +Dealing with Untrusted Input in SMM +=================================== + +Objective +--------- +Intel Security recently held a talk and published +[slides](http://www.intelsecurity.com/advanced-threat-research/content/data/REConBrus...) +on a vulnerability in SMM handlers on x86 systems. They provide examples +on how both UEFI and coreboot are affected. + +Background +---------- +SMM, the System Management Mode, is a CPU mode that is configured by +firmware and survives the system’s initialization phase. On certain +events that mode can be triggered and executes code, suspending the +current processing that is going on the CPU, no matter whether it’s +in kernel or user space. + +In SMM, the CPU has access to memory dedicated to that mode (SMRAM) that +is normally inaccessible, and typically some restrictions are lifted as +well (eg. in some configurations, certain flash write protection registers +are writable in SMM only). This makes SMM a target for attacks which +seek to elevate a ring0 (kernel) exploit to something permanent. + +Overview +-------- +Intel Security showed several places in coreboot’s SMM handler (Slides +32+) that could be manipulated into writing data at user-chosen addresses +(SMRAM or otherwise), by modifying the BAR (Base Address Register) on +certain devices. By picking the right addresses and the right events +(and with them, mutators on the data at these addresses), it might +be possible to change the SMM handler itself to call into regular RAM +(where other code resides that then can work with elevated privileges). + +Their proposed mitigations (Slide 37) revolve around making sure +that the BAR entries are reasonable, and point to a device instead of +regular memory or SMRAM. They’re not very detailed on how this could +be implemented, which is what this document discusses. + +Detailed Design +--------------- +The attack works because the SMM handler trusts the results of the +`pci_read_config32(dev, reg)` function, even though the value read by that +function can be modified in kernel mode. + +In the general case it’s not possible to keep the cached value from +system initialization because there are legitimate modifications the +kernel can do to these values, so the only remedy is to make sure that +the value isn’t totally off. + +For applications where hardware changes are limited by design (eg. no +user-modifiable PCIe slots) and where the running kernel is known, +such as Chromebooks, further efforts include caching the BAR settings +at initialization time and comparing later accesses to that. + +What "totally off" means is chipset specific because it requires +knowledge of the memory map as seen by the memory controller: which +addresses are routed to devices, which are handled by the memory +controller itself? +The proposal is that in SMM, the `pci_read_config` functions (which +aren’t timing critical) _always_ validate the value read from a given +set of registers (the BARs) and fail hard (ie. cold reset, potentially +after logging the event) if they’re invalid (because that points to +a severe kernel bug or an attack). +The actual validation is done by a function implemented by the chipset code. + +Another validation that can be done is to make sure that the BAR has the +appropriate bits set so it is enabled and points to memory (instead of +IO space). + +In terms of implementation, this might look somewhat as follows. There +are a bunch of blanks to fill in, in particular how to handle the actual +config space access and there will be more registers that need to be +checked for correctness, both official BARs (0-4) and per-chipset +registers that need to be blacklisted in another chipset specific +function: + +```c +static inline __attribute__((always_inline)) +uint32_t pci_read_config32[d](pci_devfn_t dev, unsigned int where) +{ + uint32_t val = real_pci_read_config32(dev, where); + if (IS_ENABLED(__SMM__) && (where == PCI_BASE_ADDRESS_0) && + is_mmio_ptr(dev, where) && !is_address_in_mmio(val)) { + cold_reset(); + } + return val; +} +``` + +`is_address_in_mmio(addr)` would be a newly introduced function to be +implemented by chipset drivers that returns true if the passed address +points into whatever is considered valid MMIO space. +`is_mmio_ptr(dev, where)` returns true for PCI config space registers that +point to BARs (allowing custom overrides because sometimes additional +registers are used to point to addresses). + +For this function what is considered a legal address needs to be +documented, in accordance with the chipset design. (For example: AMD +K8 has a bunch of registers that define strictly which addresses are +"MMIO") + +### Fully insured (aka “paranoid”) mode +For systems with more control over the hardware and kernel (such as +Chromebooks), it may be possible to set up the BARs in a way that the +kernel isn’t compelled to rewrite them, and store these values for +later comparison. + +This avoids attacks such as setting the BAR to point to another device’s +MMIO region which the above method can’t catch. Such a configuration +would be “illegal”, but depending on the evaluation order of BARs +in the chipset, this might effectively only disable the device used for +the attack, while still fooling the SMM handler. + +Since this method isn’t generalizable, it has to be an optional +compile-time feature. + +Caveats +------- +This capability might need to be hidden behind a Kconfig flag +because we won’t be able to provide functional implementations of +`is_address_in_mmio()` for every chipset supported by coreboot from the +start. + +Security Considerations +----------------------- +The actual exploitability of the issue is unknown, but fixing it serves +as defense in depth, similar to the +[Memory Sinkhole mitigation](https://review.coreboot.org/#/c/11519/) for +older Intel chipsets. + +Testing Plan +------------ +Manual testing can be conducted easily by creating a small payload that +provokes the reaction. It should test all conditions that enable the +address test (ie. the different BAR offsets if used by SMM handlers).