ACPI and SMI handlers: some limits to trusted computing

Abstract

Trusted computing has been explored through several international initiatives. Trust in a platform generally requires a subset of its components to be trusted (typically, the CPU, the chipset and a virtual machine hypervisor). These components are granted maximal privileges and constitute the so called Trusted Computing Base (TCB), the size of which should be minimal. The rest of the platform is only granted limited privileges and cannot perform security-critical operations. A few initiatives aim at excluding the BIOS from the TCB in particular (e.g., Intel TxT and AMD SVM/SKINIT). However, the BIOS is responsible for providing some objects that need to be trusted for the computer to work properly. This paper focuses on two of these objects, the SMI handler and the ACPI tables, which are responsible for the configuration and the power management of the platform. We study to what extent these two components shall reasonably be trusted. Despite the protections that are implemented, we show that an attacker can hide functions in either structure to escalate privileges. The main contributions of our work are to present an original mechanism that may be used by attackers to alter the SMI handler, and to describe how rogue functions triggered by an external stimulus can be injected inside ACPI tables (in our case, the attacker will plug and unplug the power supply twice in a row). We also explore the countermeasures that would prevent such modifications.

Automated Verification of Dynamic Root of Trust Protocols

“…Our models fall in the latter case, and we have to further inspect the output trace to see how its steps can be used to reconstruct a valid trace: we do observe in the output trace the expected intermediary messages on the channels cpu tpm and os, and we can follow the source of these messages up to a dynamic root of trust request, of whose validity we have to again make sure. By a similar analysis of attack traces returned by ProVerif, we can observe the attacks of [13,29] in our models, when we allow the STM to be modified arbitrarily.…”

“…That is why the SMI handler is stored in a memory area called SMRAM, which enjoys special hardware protection. Still, as shown in [13,29], the security guarantees of trusted computing can be violated using the CPU caching mechanism to compromise the SMI handler. Roughly, these attacks work because the protection of the SMRAM is not carried on to its cached contents.…”

“…While our model takes into account at an abstract level the attacks and mitigations of [13,29], further refinements and soundness results are necessary in order to be able to conclude that attacks such as these or as [31,30] are not possible in practice. We need to develop models that are abstract enough to allow clear specifications and automated reasoning, and realistic enough to capture for instance implementation flaws.…”

“…However, turning this idea into a secure design and implementation is not easy, as various attacks have shown [13,29]. For more assurance, one could use models and tools that allow automated verification of desired properties against trusted computing protocols and implementations.…”