AMD Secure Encrypted Virtualization (SEV) patch for Linux kernel

Brijesh Singh of AMD submitted a 28-part patch to the Linux-(kernel,efi,kvm,…) mailing lists, with a patch for the the Linux kernel to support AMD’s Secure Encrypted Virtualization (SEV), which relies on the recent AMD Secure Memory Encryption (SME) patch by Tom Lendacky of AMD. I’m excerpting the intro text from part 1/28:

[RFC PATCH v1 00/28] x86: Secure Encrypted Virtualization (AMD)

This RFC series provides support for AMD’s new Secure Encrypted Virtualization (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFC.

SEV is an extension to the AMD-V architecture which supports running multiple VMs under the control of a hypervisor. When enabled, SEV hardware tags all code and data with its VM ASID which indicates which VM the data originated from or is intended for. This tag is kept with the data at all times when inside the SOC, and prevents that data from being used by anyone other than the owner. While the tag protects VM data inside the SOC, AES with 128 bit encryption protects data outside the SOC. When data leaves or enters the SOC, it is encrypted/decrypted respectively by hardware with a key based on the associated tag.

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.

SEV is designed to protect guest VMs from a benign but vulnerable (i.e. not fully malicious) hypervisor. In particular, it reduces the attack surface of guest VMs and can prevent certain types of VM-escape bugs (e.g. hypervisor read-anywhere) from being used to steal guest data.

The RFC series also includes a crypto driver (psp.ko) which communicates with SEV firmware that runs within the AMD secure processor provides a secure key management interfaces. The hypervisor uses this interface to enable SEV for secure guest and perform common hypervisor activities such as launching, running, snapshotting , migrating and debugging a  guest. A new ioctl (KVM_SEV_ISSUE_CMD) is introduced which will enable Qemu to send commands to the SEV firmware during guest life cycle.

The RFC series also includes patches required in guest OS to enable SEV feature. A guest OS can check SEV support by calling KVM_FEATURE cpuid  instruction.

The following links provide additional details:

AMD Memory Encryption whitepaper:

http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf

AMD64 Architecture Programmer’s Manual:
http://support.amd.com/TechDocs/24593.pdf
SME is section 7.10
SEV is section 15.34

Secure Encrypted Virutualization Key Management:
http://support.amd.com/TechDocs/55766_SEV-KM%20API_Spec.pdf

See the full patch for more information.
https://lkml.org/lkml/2016/8/22/960

more info for AMD Secure Memory Encryption (SME) for Linux

A follow-up to:

https://firmwaresecurity.com/2016/04/26/amds-secure-memory-encryption-sme-and-secure-encrypted-virtualization-sev/

Tom Lendacky of AMD posted v2 of a 20-part patch to most of the linux-kernel (and other) lists, adding support for AMD Secure Memory Encryption (SME), adding more documentation about AMD SME.

Secure Memory Encryption (SME) is a feature found on AMD processors.
SME provides the ability to mark individual pages of memory as encrypted using the standard x86 page tables.  A page that is marked encrpyted will be automatically decrypted when read from DRAM and encrypted when written to DRAM.  SME can therefore be used to protect the contents of DRAM from physical attacks on the system.
[…]
BOOT data (such as EFI related data) is not encyrpted when the system is booted and needs to be accessed as non-encrypted.  Add support to the early_memremap API to identify the type of data being accessed so that the proper encryption attribute can be applied.  Currently, two types of data are defined, KERNEL_DATA and BOOT_DATA.
[…]
Documentation/x86/amd-memory-encryption.txt

http://vger.kernel.org/majordomo-info.html

Also check out the older v1 patch posting on the lists, there was some interesting technical discussion. The above previous blog post has a pointer to that discussion, as well as some other AMD specs.

AMD’s Secure Memory Encryption (SME) and Secure Encrypted Virtualization (SEV)

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.

AMD Memory Encryption whitepaper:

Click to access AMD_Memory_Encryption_Whitepaper_v7-Public.pdf

AMD64 Architecture Programmer’s Manual:

Click to access 24593.pdf

SME is section 7.10
SEV is section 15.34

https://lkml.org/lkml/2016/4/26/1109
https://lkml.org/lkml/2016/4/26/1114
http://www.amd.com/en-us/innovations/software-technologies/security
http://www.amd.com/en-us/solutions/pro/security-manageability

For the patch, see the Linux-kernel or Linux-EFI (or other) lists:
http://vger.kernel.org/majordomo-info.html