White Paper
AMD SEV-SNP:
Strengthening VM Isolation with Integrity Protection and More
January, 2020
Copyright By PowCoder代写 加微信 powcoder
This white paper is a technical explanation of what the discussed technology has been designed to accomplish. The actual technology or feature(s) in the resultant products may differ or may not meet these aspirations. Each description of the technology must be interpreted as a goal that AMD strived to achieve and not interpreted to mean that any such performance is guaranteed to be fully achieved. Any computer system has risks of security vulnerabilities that cannot be completely prevented or mitigated.
DISCLAIMER
The information contained herein is for informational purposes only, and is subject to change without notice. While every precaution has been taken in the preparation of this document, it may contain technical inaccuracies, omissions and typographical errors, and AMD is under no obligation to update or otherwise correct this information. Advanced Micro Devices, Inc. makes no representations or warranties with respect to the accuracy or completeness of the contents of this document, and assumes no liability of any kind, including the implied warranties of noninfringement, merchantability or fitness for particular purposes, with respect to the operation or use of AMD hardware, software or other products described herein. Any computer system has risks of security vulnerabilities that cannot be completely prevented or mitigated. No license, including implied or arising by estoppel, to any intellectual property rights is granted by this document. Terms and limitations applicable to the purchase or use of AMD’s products are as set forth in a signed agreement between the parties or in AMD’s Standard Terms and Conditions of Sale.
AMD, the AMD Arrow logo, and combinations thereof are trademarks of Advanced Micro Devices, Inc. Other product names used in this publication are for identification purposes only and may be trademarks of their respective companies.
© 2020 Advanced Micro Devices, Inc. All rights reserved.
Introduction
In 2016, AMD introduced Secure Encrypted Virtualization (SEV), the first x86 technology designed to isolate virtual machines (VMs) from the hypervisor. While hypervisors have traditionally been trusted components in the virtualization security model, many markets can benefit from a different VM trust model. In the cloud for instance, customers may want to secure their VM-based workloads from the cloud administrator to keep their data confidential and minimize their exposure to bugs in the cloud provider’s infrastructure. This leads to a desire to isolate VMs at a hardware level from the hypervisor and other code that may happen to coexist on the physical server.
AMD began tackling this challenge through the use of main memory encryption in SEV. With this technology, individual VMs could be assigned a unique AES encryption key that is used to automatically encrypt their in-use data. When a component such as the hypervisor attempts to read memory inside a guest, it is only able to see the encrypted bytes.
In 2017, AMD introduced the SEV-ES (Encrypted State) feature which added additional protection for CPU register state. In SEV-ES, the VM register state is encrypted on each hypervisor transition so that the hypervisor cannot see the data actively being used by the VM. Together with SEV, SEV-ES can reduce the attack surface of a VM by helping protect the confidentiality of data in memory.
This white paper introduces the next generation of SEV called SEV-SNP (Secure Nested Paging). SEV-SNP builds upon existing SEV and SEV-ES functionality while adding new hardware-based security protections. SEV-SNP adds strong memory integrity protection to help prevent malicious hypervisor- based attacks like data replay, memory re-mapping, and more in order to create an isolated execution environment. Also, SEV-SNP introduces several additional optional security enhancements designed to support additional VM use models, offer stronger protection around interrupt behavior, and offer increased protection against recently disclosed side channel attacks.
This white paper refers to SEV, SEV-ES, and SEV-SNP collectively as AMD SEV technologies.
The Case for Integrity
AES encryption, as used with AMD SEV technologies, provides increased confidentiality protection of memory. An attacker without knowledge of the encryption key cannot decipher VM data that is stored in DRAM. The SEV memory encryption key itself is generated from a hardware random number generator and is stored in dedicated hardware registers where software cannot directly read it. Additionally, the hardware is designed so that identical plaintext at different memory locations will encrypt differently.
Despite the encryption, a motivated attacker may attempt to change values in memory, even without knowing the encryption key. These types of attacks are referred to as integrity attacks because the values in memory are not the same as what the VM intended. While an attacker cannot easily put known data into a VM’s memory without knowledge of the encryption key, they may be able to corrupt memory so that the VM sees random values or conduct replay attacks. In a replay attack, an attacker captures ciphertext at one point in time and later replaces memory with the earlier captured data. This type of attack is more effective if the attacker knew what the original data was.
Integrity attacks by themselves do not directly compromise a VM. Software inside the VM must utilize the incorrect data, leading to a compromise or information disclosure. Whether such an attack is successful or not is dependent on the software inside the VM and how it behaves when encountering this compromised data. As the software in the VM is generally not aware if its memory integrity has been compromised, its behavior in this situation can be challenging to predict.
SEV-SNP is designed to prevent software-based integrity attacks and reduce risk associated with compromised memory integrity. The basic principle of SEV-SNP integrity is that if a VM is able to read a private (encrypted) page of memory, it must always read the value it last wrote. This means that if the VM wrote a value A to memory location X, whenever it later reads X it must either see the value A or it must get an exception indicating the memory could not be read. SEV-SNP is designed so that the VM should not be able to see a different value from memory location X.
To support standard VM tasks, this guarantee must hold regardless of what happens to memory in between the read and the last write. If that memory page is swapped to a disk, or even if the entire VM is migrated to a new host, the integrity guarantee must still hold. Enforcing this integrity guarantee requires a combination of new CPU hardware and firmware discussed later in this white paper.
In typical use cases, VMs must both execute their own tasks and communicate with outside entities via I/O. This may include communication over a network link, with a storage server, or with other components. In the SEV architecture, this communication is done using shared (unencrypted) memory. Any outgoing data that a VM desires to make available is placed into a shared page of memory, and any incoming data must similarly be placed into a shared page. Because shared memory is not encrypted with the VM’s specific key, appropriate software encryption protocols like HTTPS should be used for security of I/O traffic.
AMD SEV VMs control whether a memory page is private or shared using the enCrypted bit (C-bit) in the guest page tables. The location of the C-bit is implementation defined and may be the top physical address bit as shown in Figure 1. Shared (unencrypted) memory is marked C=0 by the VM, indicating it does not have to be encrypted with the VM’s memory encryption key.
Private (encrypted) memory pages are for the exclusive use of that VM and are marked as C=1. In a typical VM, most pages are
marked private, and only the select pages needed for outside communication are marked shared. As with the SEV confidentiality guarantees, the SEV-SNP integrity guarantees only apply to private guest pages.
Unencrypted
Virtual Address
Virtual Address
Physical Address
Physical Address
AES Encryption
FIGURE 1: ENCRYPTION CONTROL
Threat Model Details
As with the previous SEV and SEV-ES features, under SEV-SNP the AMD System-On-Chip (SOC) hardware, the AMD Secure Processor (AMD-SP), and the VM itself are all treated as fully trusted. The VM is responsible for protecting itself and its interfaces, and it should follow standard best practices for protecting any I/O data it uses such as network traffic, hard disk data, etc. To this end, AMD highly recommends using a Full Disk Encryption (FDE) solution with protected VMs since all SEV technologies only protect data in-use. FDE protects data-at-rest and many popular commercial solutions exist.
Under SEV-SNP, all other CPU software components and PCI devices are treated as fully untrusted as shown in Figure 2. This includes the BIOS on the host system, the hypervisor, device drivers, other VMs, etc. Fully untrusted means these components are assumed to be malicious, potentially conspiring with other untrusted components in an effort to compromise the security guarantees of an SEV-SNP VM.
AMD Hardware and Firmware
External PCI Devices (e.g., NIC, HDD)
Device Drivers
Hypervisor
Cloud Management Software
= Untrusted
Legacy Legacy
(unencrLyepgtaecdy) (unencrypted)
(uVnMenscrypted) VMs
Legacy Legacy
(unencrypted) (unencrypted)
OtVheMrsSNP VMs VMs
FIGURE 2: SEV-SNP THREAT MODEL
The SEV-SNP threat model includes features that are designed to protect against additional threats than previous AMD SEV technologies. SEV and SEV-ES use the threat model of a “benign but vulnerable” hypervisor. In this threat model, the hypervisor is not believed to be 100% secure, but it is trusted to act with benign intent. Meaning that while the hypervisor was not actively trying to compromise the SEV VMs underneath it, it could itself have exploitable vulnerabilities. By either blocking or making certain attacks more difficult, SEV and SEV-ES technologies can help limit the potential exposure of certain classes of hypervisor bugs or raise the difficulty of exploitation significantly. SEV-SNP addresses additional attack vectors and potential threats to VM security. The threats which are and are not addressed by various SEV technologies are summarized in Table 1.
Confidentiality: As noted, confidentiality threats are handled through the hardware-based memory encryption present in all current SEV technologies. This prevents an untrusted component, such as the hypervisor or a DMA-capable device, from being able to directly read the plaintext inside a
VM (except of course in cases where the VM has opted to allow untrusted access to a page). The SEV-ES technology added confidentiality protection for VM register state, encrypting this state when the VM exits back to the hypervisor. This protection exists in SEV-SNP as well.
Integrity: SEV-SNP technology is designed to protect against integrity attacks, which include data replay, corruption, re-mapping, and aliasing based attacks. The guarantee that a VM always sees the data it last wrote implies that all these attack vectors must be prevented.
Availability: There are two aspects of availability with any virtualization platform. The first is ensuring that the hypervisor retains control of the system, and the guest VM is not able to deny the hypervisor from running or otherwise render the physical machine unusable. All SEV technologies support this level of availability and guarantee that the hypervisor can always regain control when it desires (e.g., via a physical timer interrupt) or terminate a guest at any time without the consent of that VM. The second aspect of availability is whether the guest enjoys any guarantees of availability such as a minimum run-time. This is not part of any of the SEV technology threat models as a malicious hypervisor can always choose never to run some or all of a guest VM.
Physical Access Attacks: While certain physical attacks such as DRAM cold boot attacks (where DRAM chips are analyzed off-line) can be blocked by these technologies, on-line DRAM integrity attacks, such as attacking the DDR bus while the VM is actively running, are out of scope. These attacks are very complex and require a significant level of local access and resources to perform.
Miscellaneous: There are several other types of potential attacks against secure VMs, some of which are in-scope in this threat model. For instance, SEV-SNP includes features to help prevent Trusted Computing Base (TCB) rollback attacks. As discussed later, this enables a cryptographic means to verify that the AMD-SP firmware and other trusted components in the system meet the policy of the VM.
Additionally, SEV-SNP optionally supports the ability to restrict how interrupts and exceptions can be injected into a VM. It can also support Branch Target Buffer (BTB) protection against certain types of side channel attacks. Both protections are discussed later in this white paper.
Lastly, there are certain classes of attacks that are not in scope for any of these three features. Architectural side channel attacks on CPU data structures are not specifically prevented by any hardware means. As with standard software security practices, code which is sensitive to such side channel attacks (e.g., cryptographic libraries) should be written in a way which helps prevent such attacks. Fingerprinting attack protection is also not supported in the current generation of these technologies. Fingerprinting attacks attempt to determine what code the VM is running by monitoring its access patterns, performance counter information, etc. While fingerprinting can sometimes provide information about the code being run inside a VM, typically the most sensitive information is the data itself (e.g., data in the database), not the code being run (e.g., which version of the database software is being used). The current set of SEV technologies therefore focuses primarily on protecting the sensitive VM data contents. Additional protection against certain fingerprinting attacks may be offered in future SEV technologies.
= Mitigated = Optionally Mitigated = Not Mitigated
SEV SEV-ES
Confidentiality
Potential Threats
Example attack: Hypervisor reads private VM memory
VM Register State
Example attack: Read VM register state after VMEXIT
DMA Protection
Example attack: Device attempts to read VM memory
Replay Protection
Example attack: Replace VM memory with an old copy
Data Corruption
Example attack: Replace VM memory with junk data
Memory Aliasing
Example attack: Map two guest pages to same DRAM page
Memory Re-Mapping
Example attack: Switch DRAM page mapped to a guest page
Availability
Denial of Service on Hypervisor
Example attack: Malicious guest refuses to yield/exit
Denial of Service on Guest
Example attack: Malicious hypervisor refuses to run guest
Physical Access Attacks
Offline DRAM analysis
Example attack: Cold boot
Active DRAM corruption
Example attack: Manipulate DDR bus while VM is running
TCB Rollback
Example attack: Revert AMD-SP firmware to old version
Malicious Interrupt/Exception Injection
Example attack: Inject interrupt while RFLAGS.IF=0
Indirect Branch Predictor Poisoning
Example attack: Poison BTB from hypervisor
Secure Hardware Debug Registers
Example attack: Change breakpoints during debug
Trusted CPUID Information
Example attack: Hypervisors lies about platform capabilities
Architectural Side Channels
Example attack: PRIME+PROBE to track VM accesses
Page-level Side Channels
Example attack: Track VM access patterns through page tables
Performance Counter Tracking
Example attack: Fingerprint VM apps by performance data
TABLE 1: THREAT MODEL
DATA CORRUPTION
MEMORY RE-MAPPING
TABLE 2: INTEGRITY THREATS
Integrity Threats
DESIRED SECURITY PROPERTY SEV-SNP ENFORCEMENT MECHANISM
Only the owner of a memory page can write Reverse Map Table (RMP) that page
Every guest page can map only to a single Page Validation physical memory page at one time
REPLAY PROTECTION
Only the owner of a memory page can write Reverse Map Table (RMP) that page
MEMORY ALIASING
Every physical memory page can map only to a Reverse Map Table (RMP) single guest page at one time
The previous section highlighted four unique types of integrity threats: Replay Protection, Data Corruption, Memory Aliasing, and Memory Re-Mapping. Protecting against these threats requires the enforcement of different security properties as shown in Table 2. In the case of Replay Protection and Data Corruption based attacks, these attacks rely on untrusted code being able to write to the memory of a protected VM. SEV-SNP addresses this by enforcing that only the owner of a memory page (e.g., the SEV-SNP VM to which the page was assigned) may write to that page. This enforcement is done using the Reverse Map Table (RMP) mechanism described in the following section.
Memory Aliasing attacks involve the hypervisor maliciously simultaneously mapping two different guest pages to the same physical memory page. A guest naturally expects that different pages in its guest physical address space map to different memory so any aliasing could lead to unintentional data corruption. Addressing this threat requires ensuring that every physical page of memory can only be mapped to one guest page at a time. Again, the RMP structure is used to enforce this property.
The final integrity threat, Memory Re-Mapping, involves the hypervisor maliciously re-mapping a single guest page to multiple different physical memory pages. In this threat, the guest might see an inconsistent view of memory where only a subset of data it wrote appears in memory. Addressing this threat requires ensuring that every guest page only maps to a one page of physical memory at a time, and that this mapping cannot be changed except by trusted entities like the AMD-SP. SEV-SNP uses a mechanism called Page Validation to address this threat. Page Validation relies on a combination of the new RMP mechanism with new VM code to manage the injective relationship between guest memory and system memory.
Reverse Map Table
As mentioned, many of the integrity guarantees of SEV-SNP are enforced through a new structure called the Reverse Map Table (RMP). The RMP is a single data structure shared across the system that contains one entry for every 4k page of DRAM that may be used by VMs. The goal of the RMP is simple: it tracks the owner for each page of memory. Pages of memory can be owned by the hypervisor, owned by a specific VM, or owned by the AMD-SP. Access to memory is controlled so only the owner of that page can write it. The RMP is used in conjunction with standard x86 page tables to enforce memory restrictions and page access rights.
The RMP is indexed by system physical address and is checked at the end of CPU and IOMMU table-walks. For example, in native (non-VM) mode, virtual addresses are translated into physical addresses using the standard x86 page tables. After that translation, the final physical address is used to index the RMP. The RMP entry is read out and checked. If the RMP entry indicates that the page is a hypervisor-owned page, then the checks pass and a new TLB entry is created. If the RMP entry indicates that the page is not a hypervisor-owned page though, the table-walk faults (#PF) and the access is denied.
When running in an SEV-SNP VM, the RMP check is slightly more complex. As with native mode, the virtual address is first translated into a system physical address. In this case, AMD-V 2-
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com