6.4 Requirement 4 - In-Context Privileged Measurement
HyperSentry notes that for In-Context Privileged Measurement that the mea- surement agent should be privileged "and in the right context to access the hypervisor’s code and data, and to gain full access to the CPU’s state [7]." While an SMM-RIMM has the privilege to look deeply within the monitored
environment, the challenge becomes how to interpret what it observes, as SMM does not natively understand internal operating system or hypervisor data structures. SMM would not know whether the host software is Windows 8, Windows 10, Linux, or Xen. Compounding the challenge, operating sys- tems or hypervisors utilize internal data structures that differ from each other and vary between revisions. For example, Xen features a "Grant Table" data structure that controls which memory pages a virtual machine is allowed to map. As this data structure is Xen-specific, SMM is not aware of its existence. SMM is also not aware that Xen supports two different versions of the Grant Table data structure [97] but would need to understand the layout of the appropriate version in order to properly measure it.
Previous SMM-RIMMs have dealt with this challenge in several different ways. SPECTRE built in operating system-specific knowledge into their SMM measurement agent [119]. To identify physical memory addresses for SMM to measure, SPECTRE utilized an observation that in Linux and Windows, virtual addresses above addresses 0xC0000000 and 0x80000000, respectively are considered kernel space. To find the physical memory address, an offset is subtracted from the virtual address. SPECTRE employs a similar method to find the location of the Kernel Processor Control Region (KPCR) which controls a sequence of data structures that control processes and threads in order to measure it. The authors note that this data structure resides at virtual address 0xFFDFF000 and rely upon known memory offsets to parse the data structure.
The issue with this approach is that it assumes a kernel data structure layout that can vary depending on version. Also kernel address space ran- domization (KASLR) breaks these assumptions as code can be located at different addresses each boot. Thus, this method of hard-coding addresses
Chapter 6. EPA-RIMM Design Requirements 110
and offsets is brittle and would require BIOS updates to update SPECTRE’s assumptions. HyperSentry resolved this tension by placing their measure- ment agent within the hypervisor. This allows the agent to directly leverage hypervisor data structures and layouts in its measurements. EPA-RIMM keeps the measurement agent within SMM and utilizes information gleaned from a provisioning phase to direct the measurements. Changes in layout and offsets can be accounted for in the data structures that the EPA-RIMM measurement agent receives.
6.5 Requirement 5 - Attestable Output
It is important that the output of an SMM-RIMM be trustable. If the SMM- RIMM were to output a result but host software were to tamper with the output, attacks would go unnoticed. For this reason, it is essential for an SMM- RIMM to output its results such that they can be verified at the receiving end. This includes using signing, encryption, and message authentication checks. These mechanisms would provide the ability to detect malicious tampering with in-transit results. Similarly, if malicious host software were to prevent the SMM-RIMM from outputting any data at all, this could be detectable by the RIMM recipient not receiving any of the expected reports.
HyperSentry builds trust into the RIMM’s output by leveraging a public and private key pair to be used in verifying that the output was not forged. This mechanism places the private key in SMM’s protected SMRAM region and extends the public key to a PCR (register) on the system’s TPM. Before transmitting its results, the SMM-RIMM signs the measurements with its private key. A remote user can choose whether to accept the results based on whether the data was signed by HyperSentry’s private key. Additionally, the use of a nonce can guarantee freshness of results to avoid replay attacks
in which a previous valid but stale measurement is provided. With this mechanism, assurance over the integrity of the data can be provided by the RIMM.
6.6 New Requirement 6 - Extensible Measurements
Current SMM-RIMMs lack the ability to vary the amount of runtime checking based on performance needs or changes in the current threat environment which reduces effectiveness. Thus, we propose a new requirement for SMM- RIMMs prescribing the need for extensible measurements. Providing a pro- grammatic API allows a new set of measurements to be pushed out to the SMM-RIMMs as new checks are designed. This capability allows the RIMM’s checks to be updated as often as desired without needing to replace firmware code, allowing for a more adaptive and effective mechanism. The benefit of SMM-RIMMs can be greatly enhanced with communication between the SMM-RIMM instances. When attacks are detected on one SMM-RIMM in- stance, this information can be shared with other participating SMM-RIMMs to help prevent attacks from spreading. It can also enable more targeted inspections by focusing SMM-RIMMs on platform resources that have been compromised on one of the instances.
6.7 New Requirement 7 - Performance-aware
An ideal RIMM design would provide quick detection of attacks at a perfor- mance overhead that is imperceptible to the user. The more quickly an attack is detected, the more useful the RIMM mechanism is. The intensity of RIMM inspections has two key variables: measurement frequency and duration. A very frequent scheduling of a RIMM could have a low or a high system impact depending on measurement duration. Similarly, an inspection with a longer duration may be less impactful to the user if it were to only run once a
Chapter 6. EPA-RIMM Design Requirements 112
day. Thus, these two parameters provide tuning knobs that can be calibrated based on differing tolerances. There are practical upper limits, though, to how long the CPU threads can remain in SMM in a single session as some software has specific timing expectations which can impact correctness. Significant performance impacts can occur with prolonged check durations. Therefore, it becomes infeasible to consider approaches that conduct extensive checks within one atomic measurement session and greatly exceed the established SMI latency guidelines.
Given this limitation, it is necessary to consider time-slicing RIMM oper- ations such that they can occur more frequently and consume less time in a single RIMM measurement session. This time-sliced approach is the most promising mechanism that can accomplish complex integrity measurements over a longer period of time with fewer negative impacts.
6.8 New Requirement 8 - Constrained Measurement Agent
SMM code has traditionally been granted access to all of memory and registers. SMM-RIMMs have adopted this design model and had access to all system state to perform their measurements. However, in response to growing concerns over attacks on SMM, efforts have arisen to reduce the accesses of SMM code on contemporary platforms. The Intel STM provides one such mechanism that allows policies to be created to remove a set of accesses from the SMI handler. Given current industry trends, we propose the use of a constrained measurement agent as a requirement for SMM-RIMMs.
6.9 Conclusions
SMM-RIMMs were originally formulated in a time when awareness of the performance impacts of SMM were not understood and granting SMM full access to the system’s resources was common-place. Additionally, the concept
of extending the set of measured resources was not conceived. Our design requirements address these key limitations to enable SMM-RIMMs in the contemporary environments, while supporting the previously formulated requirements of stealthy invocations, verifiable behavior, deterministic exe- cution, In-Content privileged measurement, and attestable output. We add three new requirements: 1. Extensible measurements to better vary the set of monitored resources during inspections, 2. Performance-awareness to balance the need for checking with system performance constraints, 3. Constrained measurement agent to reduce the risk of an SMM-based measurement agent compromising the system.
114
7 Architecture
In this section, we provide an overview of EPA-RIMM’s architecture. There are three key abstractions in EPA-RIMM: Checks, Tasks, and Bins. A Check (Section 7.1) is a description of an integrity measurement with parameters to guide its execution. If a Check detects an unacceptable result (e.g. a changed result in a presumed static resource), EPA-RIMM generates an alert. At runtime, Checks are decomposed into partial resource measurements called Tasks (Section 7.2), to meet expectations for SMI latency. Tasks are scheduled in Bins (Section 7.3) to bound the work performed in one SMI session. Bin size is defined as the sum of the execution times of the Tasks it contains.
The EPA-RIMM software architecture comprises the Diagnosis Manager (Section 7.4), the Backend Manager (Section 7.5), the Oracle (Section 7.6), the Host Communications Manager (Section 7.7) and the Inspector (Section 7.8). Section 7.9 provides our security analysis of the EPA-RIMM architecture. We provide conclusions on the EPA-RIMM architecture in Section 7.10.
7.1 EPA-RIMM Checks
EPA-RIMM’s Checks consist of measurements over resource types including memory and registers. EPA-RIMM’s architecture envisions the ability to add a variety of new Checks in response to emerging attacks.
Each Check contains a command along with its arguments and a priority. Checks allow the Administrator to specify particular measurements over sets of memory regions, Control Registers, and Model-Specific Registers (MSRs). Sample Checks include the: "Kernel Code Section Range", "Hypervisor Code Section Range" Check that measures the host software kernel code sections to identify code injections, the "Interrupt Descriptor Table" Check that measures
the contents of the Interrupt Descriptor Table (IDT), the "Interrupt Descriptor Table Register" (IDTR) Check that verifies that the IDTR register value has not changed, the "Global Descriptor Table" (GDT) Check that measures the Global Descriptor Table to determine if it has changed. Other Checks measure specific MSRs or CPU control registers, for example, to determine if the Write Protect bit on CR0 was cleared or the Supervisor Mode Execution Protection (SMEP) on CR4 were disabled by a rootkit. Figure 7.1 shows several sample Checks.