# AMD SEV Secure Nested Paging (SEV-SNP) Links: [[AMD]], [[AMD SEV]], [[EPYC]] ## Resources ### [SEV Secure Nested Paging Firmware ABI Specification](https://www.amd.com/system/files/TechDocs/56860.pdf) (124 page spec) [[2022-01]] ## [AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More](https://www.amd.com/en/processors/amd-secure-encrypted-virtualization) (Whitepaper) [[2020-01]] (entire paper except sections marked as skipped) **[[SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf]]** - It's well-written, concise, and describes concepts clearly. ### 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. ![[Screen Shot 2022-02-13 at 4.56.37 PM.png]] ### 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.== ^906dc9 - It looks like the protection does not extend to the integrity of data persisted on disk. In the context of [[-Lexe/Lexe]], a malicious host could perhaps infer which file is a channel backup, and trick the VM into publishing an invalid state by removing the latest channel backup, in the case of [[Poon-Dryja payment channels]]. ^5b27df 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. ![[Screen Shot 2022-02-13 at 5.04.49 PM.png]] 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. ^8743e2 - This basically disqualifies this technology for usage with [[-Lexe/Lexe]], as it fails the 'non-custodial' requirement. **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. ^195180 - Disqualifies [[AMD SEV]] for usage with [[-Lexe/Lexe]] **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. ![[Screen Shot 2022-02-13 at 5.15.18 PM.png]] ### (skipped sections) - Integrity Threats - Reverse Map Table - Page Validation - Page States - Virtual Machine Privilege Levels - Interrupt/Exception Protection - Trusted Platform Information - TCB Versioning ### VM Launch & Attestation As with previous SEV and SEV-ES architectures, SEV-SNP VMs start from an initial unencrypted image. This initial image is expected to contain things like the guest VM boot code, but as it starts unencrypted, it should not contain any secrets. During the launch process, the hypervisor asks the AMD-SP to install this initial set of pages in the guest. The AMD-SP cryptographically measures the contents of these pages into a launch digest. In the SEV-SNP architecture, the AMD-SP also measures the metadata associated with these pages, namely the GPA where the pages are being placed and the type of page they are. This ensures that the launch digest captures the layout of initial guest memory, as well as its contents. In SEV-SNP, at the end of the launch process, the guest owner can supply a signed Identity Block (IDB) to associate with the VM. The IDB contains fields that allow the guest owner to uniquely identify the VM and contains the expected launch digest. The IDB can only be associated with VMs which match the expected launch digest and is included as part of the attestation report. While SEV and SEV-ES only support attestation during guest launch, SEV-SNP supports more flexible attestation. Attestation reports can be requested through a protected path from the AMD-SP by the guest VM at any time. As part of SEV-SNP VM launch, a set of private communication keys are created by the AMD-SP which the guest can use to communicate directly with the AMD-SP. The guest can use this path to request attestation reports, cryptographic keys, and more. ![[Screen Shot 2022-02-13 at 5.23.21 PM.png]] Attestation reports contain the IDB information from launch, system information, and a block of arbitrary data supplied by the guest VM as part of the report request. The attestation report is signed by the AMD-SP firmware using the VCEK. Attestation reports enable a third party, such as the guest owner, to validate that certain data came from a certain VM. For example, a VM can publish a public key and ask the AMD-SP for an attestation report containing the hash of this public key as shown in Figure 10. A third party can then verify that this public key is associated with this VM through the attestation report. The attestation report also proves that the VM was running with the appropriate security features enabled, and that it started on an authentic AMD platform. Because the attestation report is signed by the VCEK, the verification of this report proves both the authenticity of the platform and the TCB version used (since the VCEK is derived from the TCB version). Upon successful attestation, a third party such as the guest owner can then choose to provide the VM with secrets, such as a disk decryption key, or other keys required for operation. Besides remote attestation, SEV-SNP supports additional use models for generating guest key material. SEV-SNP VMs may request keys directly from the AMD-SP for various purposes such as data sealing. These keys may be derived from different sources, and the VM may select which sources are used as needed for their use case. For instance, local sealing keys can be requested which are specific to the current part at a certain TCB level and specific to the IDB signing key. Through these controls, the VM may request keys that are guaranteed to not be able to be derived by a malicious actor or another device. ### (another skipped section) - VM Migration ### Side Channels A lot of security research has recently focused on CPU side channel attacks, which are attacks that leverage the internal structures of the CPU to leak information . Speculative side channel attacks such as Spectre have been demonstrated leveraging standard techniques like hardware branch prediction to create data leakage in certain scenarios. AMD has added hardware capabilities to help software defend itself against certain attacks, like Spectre Variant 2. Spectre Variant 2 demonstrated that the indirect branch predictor (BTB) can be exploited given certain software circumstances, and assuming an attacker is able to influence the branch predictions of another entity. In recent CPU designs, AMD has added support for the SPEC_CTRL MSR and PRED_CMD MSR which enables more software control of the BTB structure. In the SEV-SNP architecture, the SPEC_CTRL MSR is virtualized allowing the guest to choose its own speculation policy independent of the hypervisor. This allows the guest to use modes such as IBRS. In traditional virtualization, the hypervisor takes steps to protect itself from guest-based attacks. This may include techniques like retpoline or running with IBRS set. When the hypervisor is not trusted, the guest also may be concerned with hypervisor-based attacks. For instance, a malicious hypervisor could attempt to poison the BTB entries the guest will use or may try to use another VM to poison the BTB before the SEV-SNP guest runs. To protect against such attacks, SEV-SNP VMs may opt into additional protection whereby the CPU hardware will prevent the VM from speculatively using BTB entries installed by another entity. This feature tracks when BTB entries are installed by either the hypervisor or other software and will automatically perform a BTB flush when required so that the SEV-SNP VM does not speculatively use those BTB entries. Simultaneous Multi-Threading (SMT) is another area of CPU hardware that has been a focus of side channel research. Due to the shared hardware resources in SMT designs, more channels of observation are possible. SEV-SNP VMs that believe themselves to be particularly sensitive to such observation may opt into a policy which restricts them to only being run on SMT-disabled systems. While SEV-SNP offers guests several options when it comes to protection from speculative side channel attacks and SMT, it is not able to protect against all possible side channel attacks. For example, traditional side channel attacks on software such as PRIME+PROBE are not protected by SEV-SNP. These types of attacks require specifically targeting software algorithms that are vulnerable to these types of side channels, typically because they involve code paths which vary their cache or TLB access patterns based on a secret value. Modern cryptographic libraries take special care to avoid such behavior as these types of attacks can occur even on non-virtualized platforms. Because SEV-SNP hardware is not designed to explicitly protect against such attacks, it is the responsibility of VM owners to follow standard security practices and ensure their libraries and software are updated to not use algorithms which may be vulnerable to these attacks. Another category of side channel attacks which are outside the scope of SEV-SNP include application fingerprinting attacks, such as performance or page fault monitoring. As mentioned earlier, SEV-SNP focuses primarily on protecting the data inside VMs and these types of attacks, which typically only attempt to determine what application is being run, do not directly break the confidentiality or integrity of guest VM data. Future versions of SEV may include additional protections against some of these attack vectors. ### Conclusion SEV-SNP represents an enhanced level of security and isolation for virtual machines running in untrusted hosting environments. Building upon the SEV and SEV-ES features which provided data confidentiality protection against potentially buggy hypervisors, SEV-SNP adds integrity guarantees capable of protecting VMs from malicious hypervisors. Besides integrity protection, SEV-SNP also provides new architectural flexibility in the form of multiple VMPLs, new attestation and key derivation architectures, and an arbitrarily flexible migration policy. SEV-SNP also raises the security bar by providing optional protection against malicious interrupt injection, certain speculative side channel attacks, and TCB rollback attacks. These features, like with previous SEV and SEV-ES features, are designed to be enabled at the guest operating system level, meaning that no changes to applications inside of VMs are required. VM isolation is a challenging task for a modern cloud computing environment. SEV-SNP is the first x86 architecture designed to support both confidentiality and integrity protection for isolated VMs, enabling more secure cloud computing for a variety of workloads. AMD believes that secure cloud computing is a critical workload for tomorrow’s datacenter and SEV-SNP is the next step toward that realization.