On the Limits of Hypervisor- and Virtual Machine Monitor-Based Isolation

SpecCert: Specifying and Verifying Hardware-Based Security Enforcement

“…Our effort has been originally motivated by the disclosure of several vulnerabilities targeting multiple x86 HSE mechanisms for the past few years [17,22,23,6,14]. These attacks do not benefit from a software implementation error but rather from a flaw in the hardware specifications themselves.…”

“…We take the example of the SMRAM cache poisonning attack [17,22], which has motivated the introduction of the SMRR. If an attacker can set the proper cache strategy (WB) for the SMRAM physical addresses, then the code inside the SMRAM is loaded into the cache as soon as the CPU in SMM is executing it.…”

“…When it is not in SMM, the CPU always uses the UC strategy for I/O targeting the SMRAM. SMRR have been introduced as a countermeasure of the SMRAM cache poisoning attack [17,22] which allowed an untrusted code to tamper with the copy of the SMRAM stored in the cache. The memory controller [11] receives all the CPU I/O-s which are not handled by the cache and dispatches them to the DRAM controller or to the VGA controller.…”

“…The legitimate use of a hardware mechanism can also break the security promised by another. For instance, until 2008, the x86 cache allowed to circumvent an access control mechanism exposed by the memory controller [17,22]. Secondly, hardware architectures have grown in complexity and, as a consequence, HSE mechanisms too.…”