Secure Execution Zone Requirements
The security properties desired of an SEZ heavily depend on the attack model. In the least severe of all the attack models, the adversary only has access to the platform via a network port. In such a model, the process separation provided by the OS typically provides a sufficiently secure place to execute, and no special SEZ is required. It should, however, be noted that such models typically have very large TCBs, and any vulnerability in any component inside the TCB can compromise the software trust model. The insufficiency of such an attack model is amply demonstrated by frequent security advisories affecting the major operating systems; consequently, system architects must consider more advanced attack models.
The second attack model assumes that the attacker has compromised the software stack on the platform and has access to the most privileged ring available to commercial software. However, the attacker does not have any direct access to the hardware. In such situations, hardware-based access control (for example, range-register-based access control and paging-structure-based access control) can provide a sufficiently trusted SEZ. The hardware, firmware, or software inside the TCB can cryptographically protect code and data as they leave the access-controlled environment. However, no special (cryptographic or otherwise) protection is needed on code or data living inside the access-controlled environment, while they travel on the system buses.
The most severe attack model assumes that the attacker can not only compromise the software stack, but also has some level of physical access to the platform hardware and is capable of launching simple hardware attacks, such as DIMM-removal and/or snooping the buses. This attack model is applicable in situations where the computer platform is stolen, or where the platform user might be interested in circumventing the security of the system (for example, to circumvent digital rights management (DRM) protections). This kind of attack represents one of the most challenging security problems and requires cryptographic protections on internal buses, in addition to various access-control mechanisms.
Cloning and Replay Attacks
A special kind of attack model is the cloning and replay attack. Such an attack involves a corrupted software stack that attacks an in-band SEZ. The attack involves recording the state of the SEZ and restarting the SEZ repeatedly with the same state. An attacker can change the input data to the SEZ and record the output of the SEZ. We use the term replay attack to indicate that a partial portion of the SEZ is being replayed. A cloning attack refers to attacks that replay the entire SEZ space.
A cloning or replay attack is more easily mounted against an in-band SEZ, where the SEZ is dependent on the software stack to provide resources. In order to prevent this sort of attack the SEZ must have special protections against replay. Replay and cloning attacks can be mounted remotely, if the software stack contains an exploitable vulnerability.
Required Properties of an Effective Secure Execution Zone. An SEZ environment has to have many properties to make it effective. We describe in detail these properties in this section.
Code Integrity Code integrity refers to the ability of an SEZ environment to prevent the software running inside an SEZ container from being modified by entities outside the TCB of that container. Code integrity is an absolute requirement of any SEZ environment -- any SEZ environment must protect software code running inside a container from malicious tampering by an attacker outside the container, under the applicable attack model.
Just as code integrity is an important property of an SEZ environment, so is control flow integrity. Therefore, any SEZ environment must provide this property under the applicable attack model. It should be noted that, in an x86-64 programming environment, protecting the binary code image of the software component from malicious modification is not sufficient—there are a number of other factors that can affect the outcome of the execution. For example, an x86-64 execution environment does not enforce any alignment restrictions on executable instructions. Consequently, jumping into the same binary page at an offset different from the intended offset can lead to a completely different set of instructions being executed. Additionally, x86-64 platforms allow multiple levels of address indirections, including segments, page tables, extended page tables (EPTs), and QPI-based routing/decoding. Typically, these address indirections are controlled by more than one firmware and software entity. If the attacker is allowed to control any of these levels of translation in an unrestricted fashion, then the attacker can deterministically change the outcome of the software execution. For example, the attacker can jump into unspecified offsets (by modifying the segment base), or the attacker can completely change the execution order (by changing page tables or EPTs). Thus, the SEZ must enforce controlled entry points into the protected environment. Additionally, the SEZ must protect software executing inside it by either disabling the translation, controlling the translation, checking the final translation, or any combination of these.
Data integrity, another required property of an SEZ environment, refers to the ability of the SEZ environment to prevent modifications of the static and dynamic data belonging to the SEZ container from entities outside the container. Every SEZ environment must be able to protect the data belonging to an SEZ container from malicious tampering by an attacker outside the container, under the applicable attack model. It should be noted however, that under some usage models, SEZ containers need to ensure data integrity on a portion of their data only -- the attacker may be allowed to modify the remainder of the data belonging to the SEZ container. For example, in the case of integrated graphics devices, the attacker is allowed to modify the intermediate-surface data for protected surfaces that belong to the graphics device, without affecting the trust properties, such as the high-definition digital content protection (HDCP), of the graphics device.
Data-flow integrity refers to the property that stipulates that the data belonging to an SEZ container always serve their intended purpose within that container. For example, most of the executable programs developed in native runtime environments such as C/C++/assembly associate their data with the logical address of the data. However, as explained earlier, the logical addresses go through multiple layers of address translation and redirection before being consumed by the hardware. Consequently, if an attacker controls any of the intervening translation layers, it can point the logical address of one data block to a completely different physical data block belonging to the same container, causing the data to be used in an unintended fashion. For example, consider a small web server running inside an SEZ container that maintains lists of hosts that are allowed and disallowed to establish a connection. If the attacker can modify the logical-to-physical address translations without any oversight from the SEZ, then the attacker might be able to persuade the web server to interpret the list of disallowed hosts as the list of allowed hosts, thereby circumventing the intended purpose of these lists. An SEZ environment may be required to provide a binding between the logical address and the actual data. The binding can either be provided cryptographically or by disabling, controlling, or checking the translation (or a combination of all three).
Semantic Data Integrity
Semantic data integrity is a weaker property than data-flow integrity. In data-flow integrity, data are tied to their addresses within the SEZ container and can only be accessed by that container at those addresses. In semantic data integrity, the data are grouped into semantically equivalent sets. The SEZ permits substitution within a semantically equivalent set. However, substitution across semantically different sets is not permitted. For example, on the integrated graphics device, the intermediate protected surfaces generated by the graphics device that belong to the same application context are semantically equivalent, and an attacker can substitute one surface for another. However, protected surfaces belonging to different application contexts cannot be substituted for one another. It should be noted that the substitution of semantically equivalent surfaces does not compromise the graphics trust model; although such substitution may result in the graphics device displaying garbage on the screen. For many protection models, semantic data integrity is sufficient and can be implemented at a much lower cost than full dataflow integrity.
Data confidentiality refers to the ability of an SEZ to prevent attackers from accessing the designated data in the clear. The measures required to protect the data depend on the level of access the attacker has to the system. Typically, if the attacker does not have physical access to the system, then data confidentiality can be guaranteed via access control at the hardware level, and via software and firmware managed encryption when the data are moved out of the access-controlled region. However, if the attack model allows the attacker to have physical access to the platform, then the SEZ may require hardware-based encryption on the platform buses.
Code confidentiality is where the attacker is denied access to the executing code. Again, the exact mechanism depends on the level of access the attacker has. In simple situations, mode-based access control might be sufficient. In more involved cases, SRAM-level protection, or memory encryption, might be necessary. Code confidentiality might be desired when the code contains intellectual property, such as a trade-secret algorithm or copyrighted software.
Attestation refers to the ability of the software running inside an SEZ container to prove to external entities that it is in fact running inside the SEZ container. This property is extremely important for most SEZ environments, and attestation is used for establishing trust with remote entities after the platform has been shipped to the user. Without an attestation framework, the SEZ cannot provide provable protection to software that was not provisioned at the time the platform was shipped to the user.
Resistance to Denial of Service
Some platform services require guaranteed platform resources such as memory, CPU cycles, network access, and so on. Without these resources, the services could be starved and therefore unable to perform their basic intended functions. Examples of such services include anti-virus or malware detection and battery management services, among others. Such services need an SEZ that can either protect the platform services from denial of service attacks or detect that a denial of service attack is occurring and signal an external agent.
Mutually Suspicious Applications
The same SEZ technology could be used to create multiple simultaneous instances of an SEZ environment running on the same platform. Such instances are typically mutually distrusting, and the SEZ should assure the isolation between the different instances. Each instance of an SEZ is called an SEZ container.
As well as required properties, an SEZ will be much more effective if it also has these properties:
- Friendly to operating environments
- Scalable threading, expandable memory, scalable CPU resources
- Access to system resources such as network stack, display, system services
System Management Mode as a Secure Execution Zone. The SMM of the CPU has a number of attributes that make it an interesting candidate for an SEZ. When running in a properly configured platform, SMM code enjoys isolation from the host OS and from DMA agents in the platform. Furthermore, SMM code has access to all host-accessible hardware resources in the machine. Figure 1 shows an architectural layout of SMM with respect to the rest of the system software.
SMM is entered via a system management mode interrupt (SMI), which can be generated by a platform's chipset hardware or by the CPU itself. The SMI is serviced by the SMI handler, which is typically the exclusive domain of the BIOS and is configured early in pre-boot BIOS execution. The associated configuration bits are normally locked to prevent non-BIOS code from changing the configuration once it is set. The SMI handler executes in a region of sequestered memory known as SMRAM. All memory cycles from the CPU are tagged in a manner to indicate whether the cycle originated from code running in SMM or not. Therefore, when memory cycles reach the memory controller they can be distinguished between SMM and non-SMM operation of the processor. The memory controller will route cycles to SMRAM, only if they originate from a CPU that is running in SMM. Additionally, all DMA cycles to SMRAM are denied.
SMM is typically used to provide platform-specific runtime services (for example, enabling ACPI mode during OS boot), to implement BIOS workarounds for hardware issues, and in some cases to emulate hardware (for example, PS/2 mouse and keyboard emulation for USB devices).
System Management Mode as an SEZ Host
Hardware locks prevent software from changing configuration in a way that would expose SMRAM or inhibit SMIs from occurring. Therefore, if implemented properly, the SMI handler is resistant to tampering from ring 0 host software and seems like a natural place to implement SEZ applications.
All SEZ applications have a confidentiality requirement (protection of some secret) and an integrity requirement (tamper resistance); otherwise, they would simply be written in the context of a normal OS. Furthermore, assurance or attestation of the environment is commonly required. Any candidate SEZ environment must be evaluated based on its ability to provide these properties.
Upon careful analysis, with these requirements in mind, there are a number of issues with SMM as an SEZ host:
- The SMI handler is, by definition, platform specific. Each platform may have several BIOS revisions, and each BIOS revision may change the SMI handler. Therefore, the total number of SMI implementations is very large. Gaining any reasonable level of assurance that an arbitrary SMM implementation provides sufficient confidentiality or is tamper resistant is problematic, if not intractable.
- Secret protection and assurance of secret destruction is incomplete, even with a correctly implemented SMI handler. While it may be possible to devise schemes that can defend secrets from a software attack with BIOS inside the SEZ TCB, these schemes are clearly insufficient for some classes of reasonably trivial physical attacks that are a concern for many SEZ applications.
- SMM does not scale well. OS environments tend to be very sensitive to the amount of time spent in SMM. If the time spent servicing an SMI exceeds about 300 microseconds, OS visible artifacts may become a problem. This short duration leaves very little time for any meaningful work to be done. To work around this time problem, any SMM-hosted SEZ environment would need to be scheduled by the OS. This is still likely to be insufficient, because SMM runs with all interrupts inhibited, which significantly complicates OS scheduling algorithms. Furthermore, basing SEZ time on an OS scheduler permits ring 0 denial of service attacks on SEZ applications. Finally, if the SEZ application needs access to system resources (for example, the network stack, display, storage), the device must be either dedicated to SMM or arbitrated with the OS.
- While SMM runs X86 code, no common software environment or services exist to support SEZ applications. While the Unified Extensible Firmware Interface (UEFI) may partially address this issue (heap management, for example), UEFI is far from universal, nor does it include a sufficient set of services to provide a base for SEZ applications . This lack of a common software support environment implies that an SEZ application must itself implement all of the platform support it requires. This is an ecosystem problem that has no clear solution.
While SMM provides BIOS a robust environment to implement runtime functions and services and has proven many times to be a valuable tool, it is not sufficient for SEZ usage. SMM does not provide sufficient scalability, attestability, or assurance to meet the security demands of SEZ applications.
An SEZ Based on a Virtual Machine Monitor . Since virtual machine monitors (VMMs) that use hardware support run at a higher privilege level than the OS, VMMs can be used to create in-band SEZs. VMMs are used to isolate the memory and I/O of the SEZ from the OS, by trapping on certain operations. Intel Virtualization Technology (Intel VT) can be used to virtualize OS page-table management, for example. OS independent memory isolation can be provided by inserting a layer of software under the OS, called a VMM. The VMM runs at a higher privilege level. As a result, it can force the OS to fault into the VMM and to control access to the memory ranges the OS is allowed to access. Intel Trusted Execution Technology (Intel TXT) provides a mechanism for a trusted boot of the VMM. Intel VT allows the VMM to trap on various paging events (for example, control-register accesses, translation look-aside buffer invalidation, and so on), which enables the VMM to install its own page tables that also conform to the OS's context-separation requirements. There are a number of variants of such VMM-based, page-table-management algorithms. They are commonly referred to as page-table shadowing algorithms. Intel's shadow page table partitioning approach is called virtualization-enabled integrity services (VIS) and is described in more detail in [3, 4, 5, and 6].
In summary, the VIS core manages two sets of page tables:
- Active page table (APT). This is the page table created and managed by the P-MAPS core in response to the OS's creation and manipulation of the guest page table (owned and managed by the OS).
- Protected page table (PPT). This is the page table created and managed by the P-MAPS core in response to a registration by a software module running in the guest OS. In response to the registration, the software module is measured, and a PPT is created for the SEZ, such that the rest of the OS code (running via the APT mappings) cannot execute within the address space defined by the PPT.
The setup of VIS is shown in Figure 2.