1  Dealing with Untrusted Input in SMM
  2  ===================================
  3  
  4  Objective
  5  ---------
  6  Intel Security recently held a talk and published
  7  [slides](http://www.intelsecurity.com/advanced-threat-research/content/data/REConBrussels2017_BARing_the_system.pdf)
  8  on a vulnerability in SMM handlers on x86 systems. They provide examples
  9  on how both UEFI and coreboot are affected.
 10  
 11  Background
 12  ----------
 13  SMM, the System Management Mode, is a CPU mode that is configured by
 14  firmware and survives the system’s initialization phase. On certain
 15  events that mode can be triggered and executes code, suspending the
 16  current processing that is going on the CPU, no matter whether it’s
 17  in kernel or user space.
 18  
 19  In SMM, the CPU has access to memory dedicated to that mode (SMRAM) that
 20  is normally inaccessible, and typically some restrictions are lifted as
 21  well (eg. in some configurations, certain flash write protection registers
 22  are writable in SMM only).  This makes SMM a target for attacks which
 23  seek to elevate a ring0 (kernel) exploit to something permanent.
 24  
 25  Overview
 26  --------
 27  Intel Security showed several places in coreboot’s SMM handler (Slides
 28  32+) that could be manipulated into writing data at user-chosen addresses
 29  (SMRAM or otherwise), by modifying the BAR (Base Address Register) on
 30  certain devices. By picking the right addresses and the right events
 31  (and with them, mutators on the data at these addresses), it might
 32  be possible to change the SMM handler itself to call into regular RAM
 33  (where other code resides that then can work with elevated privileges).
 34  
 35  Their proposed mitigations (Slide 37) revolve around making sure
 36  that the BAR entries are reasonable, and point to a device instead of
 37  regular memory or SMRAM. They’re not very detailed on how this could
 38  be implemented, which is what this document discusses.
 39  
 40  Detailed Design
 41  ---------------
 42  The attack works because the SMM handler trusts the results of the
 43  `pci_read_config32(dev, reg)` function, even though the value read by that
 44  function can be modified in kernel mode.
 45  
 46  In the general case it’s not possible to keep the cached value from
 47  system initialization because there are legitimate modifications the
 48  kernel can do to these values, so the only remedy is to make sure that
 49  the value isn’t totally off.
 50  
 51  For applications where hardware changes are limited by design (eg. no
 52  user-modifiable PCIe slots) and where the running kernel is known,
 53  such as Chromebooks, further efforts include caching the BAR settings
 54  at initialization time and comparing later accesses to that.
 55  
 56  What "totally off" means is chipset specific because it requires
 57  knowledge of the memory map as seen by the memory controller: which
 58  addresses are routed to devices, which are handled by the memory
 59  controller itself?
 60  The proposal is that in SMM, the `pci_read_config` functions (which
 61  aren’t timing critical) _always_ validate the value read from a given
 62  set of registers (the BARs) and fail hard (ie. cold reset, potentially
 63  after logging the event) if they’re invalid (because that points to
 64  a severe kernel bug or an attack).
 65  The actual validation is done by a function implemented by the chipset code.
 66  
 67  Another validation that can be done is to make sure that the BAR has the
 68  appropriate bits set so it is enabled and points to memory (instead of
 69  IO space).
 70  
 71  In terms of implementation, this might look somewhat as follows. There
 72  are a bunch of blanks to fill in, in particular how to handle the actual
 73  config space access and there will be more registers that need to be
 74  checked for correctness, both official BARs (0-4) and per-chipset
 75  registers that need to be blacklisted in another chipset specific
 76  function:
 77  
 78  ```c
 79  static inline __attribute__((always_inline))
 80  uint32_t pci_read_config32[d](pci_devfn_t dev, unsigned int where)
 81  {
 82  	uint32_t val = real_pci_read_config32(dev, where);
 83  	if (IS_ENABLED(__SMM__) && (where == PCI_BASE_ADDRESS_0) &&
 84  		is_mmio_ptr(dev, where) && !is_address_in_mmio(val)) {
 85  			cold_reset();
 86  	}
 87  	return val;
 88  }
 89  ```
 90  
 91  `is_address_in_mmio(addr)` would be a newly introduced function to be
 92  implemented by chipset drivers that returns true if the passed address
 93  points into whatever is considered valid MMIO space.
 94  `is_mmio_ptr(dev, where)` returns true for PCI config space registers that
 95  point to BARs (allowing custom overrides because sometimes additional
 96  registers are used to point to addresses).
 97  
 98  For this function what is considered a legal address needs to be
 99  documented, in accordance with the chipset design. (For example: AMD
100  K8 has a bunch of registers that define strictly which addresses are
101  "MMIO")
102  
103  ### Fully insured (aka “paranoid”) mode
104  For systems with more control over the hardware and kernel (such as
105  Chromebooks), it may be possible to set up the BARs in a way that the
106  kernel isn’t compelled to rewrite them, and store these values for
107  later comparison.
108  
109  This avoids attacks such as setting the BAR to point to another device’s
110  MMIO region which the above method can’t catch. Such a configuration
111  would be “illegal”, but depending on the evaluation order of BARs
112  in the chipset, this might effectively only disable the device used for
113  the attack, while still fooling the SMM handler.
114  
115  Since this method isn’t generalizable, it has to be an optional
116  compile-time feature.
117  
118  Caveats
119  -------
120  This capability might need to be hidden behind a Kconfig flag
121  because we won’t be able to provide functional implementations of
122  `is_address_in_mmio()` for every chipset supported by coreboot from the
123  start.
124  
125  Security Considerations
126  -----------------------
127  The actual exploitability of the issue is unknown, but fixing it serves
128  as defense in depth, similar to the
129  [Memory Sinkhole mitigation](https://review.coreboot.org/#/c/11519/) for
130  older Intel chipsets.
131  
132  Testing Plan
133  ------------
134  Manual testing can be conducted easily by creating a small payload that
135  provokes the reaction. It should test all conditions that enable the
136  address test (ie. the different BAR offsets if used by SMM handlers).