[…]Through ongoing collaboration with industry researchers AMD became aware that, if using the user-selectable AMD secure encryption feature on a virtual machine running the Linux operating system, an encryption key could be compromised by manipulating the encryption technology’s behavior.[…]
This vulnerability was discovered and reported to AMD by Cfir Cohen of the Google Cloud security team.
M. Morbitzer et al., “Extracting Secrets from Encrypted Virtual Machines” […an approach that allows a malicious hypervisor quick identification and theft of secrets, such as TLS, SSH or FDE keys, from encrypted virtual machines on current SEV hardware…]https://t.co/hrcZeW16Zq
Extracting Secrets from Encrypted Virtual Machines Mathias Morbitzer, Manuel Huber, Julian Horsch (Submitted on 7 Jan 2019)
AMD SEV is a hardware extension for main memory encryption on multi-tenant systems. SEV uses an on-chip coprocessor, the AMD Secure Processor, to transparently encrypt virtual machine memory with individual, ephemeral keys never leaving the coprocessor. The goal is to protect the confidentiality of the tenants’ memory from a malicious or compromised hypervisor and from memory attacks, for instance via cold boot or DMA. The SEVered attack has shown that it is nevertheless possible for a hypervisor to extract memory in plaintext from SEV-encrypted virtual machines without access to their encryption keys. However, the encryption impedes traditional virtual machine introspection techniques from locating secrets in memory prior to extraction. This can require the extraction of large amounts of memory to retrieve specific secrets and thus result in a time-consuming, obvious attack. We present an approach that allows a malicious hypervisor quick identification and theft of secrets, such as TLS, SSH or FDE keys, from encrypted virtual machines on current SEV hardware. We first observe activities of a virtual machine from within the hypervisor in order to infer the memory regions most likely to contain the secrets. Then, we systematically extract those memory regions and analyze their contents on-the-fly. This allows for the efficient retrieval of targeted secrets, strongly increasing the chances of a fast, robust and stealthy theft.
AMD SEV is a hardware feature designed for the secure encryption of virtual machines. SEV aims to protect virtual machine memory not only from other malicious guests and physical attackers, but also from a possibly malicious hypervisor. This relieves cloud and virtual server customers from fully trusting their server providers and the hypervisors they are using. We present the design and implementation of SEVered, an attack from a malicious hypervisor capable of extracting the full contents of main memory in plaintext from SEV-encrypted virtual machines. SEVered neither requires physical access nor colluding virtual machines, but only relies on a remote communication service, such as a web server, running in the targeted virtual machine. We verify the effectiveness of SEVered on a recent AMD SEV-enabled server platform running different services, such as web or SSH servers, in encrypted virtual machines. With these examples, we demonstrate that SEVered reliably and efficiently extracts all memory contents even in scenarios where the targeted virtual machine is under high load.
This is a fascinating exploitation of AMD's Secure Encrypted Virtualization – the security mechanism that decrypts and encrypts virtual machines on the fly in RAM. It can be bypassed by an evil HV so that info can be exfiltrated via HTTP, we're told https://t.co/0b9chrqdXnpic.twitter.com/R7wiGwTZU4
Modified Sections 7.10.1 and 7.10.4. Modified Sections 15.34.1, 15.34.7. Added new Section 15.34.10. Modified Section 15.35.10. Modified Appendix A, Table A-7.
Not too useful, I wish I could diff PDFs better. I wish the writers would spend a few moments more on the changelog. Here’s the titles of the above sections:
7.10.1 Determining Support for Secure Memory Encryption 7.10.4 Page Table Support 15.34.1 Determining Support for SEV 15.34.7 Restrictions 15.34.10 SEV_STATUS MSR 15.35.10 Control Register Write Traps Table A-7: Secure Virtual Machine MSRs
This RFC series provides support for AMD’s new Secure Encrypted Virtualization (SEV) feature. SEV is an extension to the AMD-V architecture which supports running multiple VMs under the control of a hypervisor. The SEV feature allows the memory contents of a virtual machine (VM) to be transparently encrypted with a key unique to the guest VM. The memory controller contains a high performance encryption engine which can be programmed with multiple keys for use by a different VMs in the system. The programming and management of these keys is handled by the AMD Secure Processor firmware which exposes a commands for these tasks. SEV guest VMs have the concept of private and shared memory. Private memory is encrypted with the guest-specific key, while shared memory may be encrypted with hypervisor key. Certain types of memory (namely instruction pages and guest page tables) are always treated as private memory by the hardware. For data memory, SEV guest VMs can choose which pages they would like to be private. The choice is done using the standard CPU page tables using the C-bit, and is fully controlled by the guest. Due to security reasons all the DMA operations inside the guest must be performed on shared pages (C-bit clear). Note that since C-bit is only controllable by the guest OS when it is operating in 64-bit or 32-bit PAE mode, in all other modes the SEV hardware forces the C-bit to a 1. KVM SEV RFC  extends the KVM_FEATURE cpuid instruction to indicate whether SEV is enabled. When SEV is enabled then OVMF can use cpuid Fn8000_001F[BX] to get the C-bit position in PTE.
Linux is about to get more secure on some AMD systems, it seems… Tom Lendacky of AMD submitted an 18-part patch to many of the Linux dev lists, to add support for AMD’s new Secure Memory Encryption (SME) feature, and to prepare for an upcoming Secure Encrypted Virtualization (SEV) patch.
SME can be used to mark individual pages of memory as encrypted through the page tables. A page of memory that is marked encrypted will be automatically decrypted when read from DRAM and will be automatically encrypted when written to DRAM. Details on SME can found in the links below. The SME feature is identified through a CPUID function and enabled through the SYSCFG MSR. Once enabled, page table entries will determine how the memory is accessed. If a page table entry has the memory encryption mask set, then that memory will be accessed as encrypted memory. The memory encryption mask (as well as other related information) is determined from settings returned through the same CPUID function that identifies the presence of the feature. The approach that this patch series takes is to encrypt everything possible starting early in the boot where the kernel is encrypted. Using the page table macros the encryption mask can be incorporated into all page table entries and page allocations. By updating the protection map, userspace allocations are also marked encrypted. Certain data must be accounted for as having been placed in memory before SME was enabled (EFI, initrd, etc.) and accessed accordingly.
This patch series is a pre-cursor to another AMD processor feature called Secure Encrypted Virtualization (SEV). The support for SEV will build upon the SME support and will be submitted later.