Semiconductor & Computer Engineering
| (11 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
{{x86 title|Secure Memory Encryption (SME)}}{{x86 isa main}} | {{x86 title|Secure Memory Encryption (SME)}}{{x86 isa main}} | ||
| − | '''Secure Memory Encryption''' ('''SME''') is an [[x86]] [[instruction set]] {{x86|extension}} introduced by [[AMD]] for page-granular memory encryption support using a single ephemeral key. A subset of SME, '''Transparent SME''' (''' | + | '''Secure Memory Encryption''' ('''SME''') is an [[x86]] [[instruction set]] {{x86|extension}} introduced by [[AMD]] for page-granular memory encryption support using a single ephemeral key. A subset of SME, '''Transparent SME''' ('''TSME'''), is a more limited form of SME used to transparently encrypt the full physical memory. '''Secure Encrypted Virtualization''' ('''SEV''') extends SME to {{x86|AMD-V}}, allowing individual VMs to run SME using their own secure keys. |
| + | |||
| + | On its {{amd|Ryzen|Ryzen Pro}} processor families, AMD brands ''TSME'' as '''Memory Guard'''. | ||
| + | |||
| + | == Motivation == | ||
| + | Servers host a great deal of data including large sets of private client information. When stored in [[main memory]] in [[plain text]], this data can be exposed to various [[user access attacks]] such as administrators scraping memory of guest data or a [[hypervisor]] bug allowing hosted guest to steal data from neighboring guest virtual machines. Furthermore, data stored in DRAM in plain text can be susceptible to [[physical access attacks]] allowing data to be stolen, especially for devices such as [[NVDIMM]]s. | ||
| + | |||
| + | The SME extension attempts to defend against those attacks by allowing the entirety of main memory to be encrypted as well as by enforcing full isolation between co-resident VMs. With the addition of SEV, this security can be extended to cloud users that can have fully private memory inaccessible to hypervisor or host software. | ||
== Overview == | == Overview == | ||
| Line 6: | Line 13: | ||
== Secure Memory Encryption == | == Secure Memory Encryption == | ||
| − | '''Secure Memory Encryption''' ('''SME''') provides the ability for software to | + | '''Secure Memory Encryption''' ('''SME''') provides the ability for software to mark certain pages to be encrypted. Marked pages are automatically decrypted and encrypted upon software read and write. All pages are encrypted using a single 128-bit ephemeral AES key which is created randomly using a [[hardware random generator]] at each boot and is not accessible by software. A new key is generated by the processor on every boot. |
== Transparent SME == | == Transparent SME == | ||
| − | '''Transparent SME''' ('''TSME''') as the name implies is a stricter subset of SME that requires no software intervention. Under TSME, all memory pages are encrypted regardless of the C-bit value. TSME is designed for legacy OS and hypervisor software that cannot be modified. Note that when TSME is enabled, standard SME as well as SEV are | + | '''Transparent SME''' ('''TSME''') as the name implies is a stricter subset of SME that requires no software intervention. Under TSME, all memory pages are encrypted regardless of the C-bit value. TSME is designed for legacy OS and hypervisor software that cannot be modified. Note that when TSME is enabled, standard SME as well as SEV are still available. TSME and SME share a memory encryption key. |
== Secure Encrypted Virtualization == | == Secure Encrypted Virtualization == | ||
| Line 17: | Line 24: | ||
SME is typically enabled by BIOS or other firmware at boot time. This is done by setting the appropriate {{x86|MSR}} bit to 1. Once activate, software can simply set the encryption C-bit (enCrypted) on the desired [[page]]. It's worth noting that the location of the C-bit is actually implementation-specific and must determined by making the appropriate {{x86|CPUID}} call. Pages with a C-bit set to 1 go through the encryption engine and are stored encrypted in memory. Likewise, pages with a C-bit set to 0 go directly to memory. This means unencrypted pages do not incur any added latency because of this feature. It's worth noting that encryption I/O pages are not allowed and must have a C-bit of 0. | SME is typically enabled by BIOS or other firmware at boot time. This is done by setting the appropriate {{x86|MSR}} bit to 1. Once activate, software can simply set the encryption C-bit (enCrypted) on the desired [[page]]. It's worth noting that the location of the C-bit is actually implementation-specific and must determined by making the appropriate {{x86|CPUID}} call. Pages with a C-bit set to 1 go through the encryption engine and are stored encrypted in memory. Likewise, pages with a C-bit set to 0 go directly to memory. This means unencrypted pages do not incur any added latency because of this feature. It's worth noting that encryption I/O pages are not allowed and must have a C-bit of 0. | ||
| + | [[File:sme sev c-bit page tables.svg|right|500px]] | ||
If SEV is supported and enabled, on each SEV-enabled VM, SME mode is enabled with that VM-specified encryption key. Under SEV, the {{x86|ASID}} field in the [[page table]] is used as the key index that identifies which encryption key is used to encrypt and decrypt the memory traffic associated with that VM. SEV-enabled VMs can control their own C-bit for memory pages they want encrypted. This allows those VMs to determine which pages are private (C-bit = 1) or shared (C-bit = 0). The location of that C-bit is the same location as defined under SME. It's worth noting that this control is limited to data page. In other words, memory accesses such as guest [[page tables]] and [[instruction fetches]] are always private, regardless of the value of the C-bit (i.e., in those cases the C-bit is a [[don't care]]). This was done in order to ensure that non-guest entities such as the hypervisor itself cannot inject their own code into the SEV-enabled guest VM. If the C-bit is an address bit, this bit is masked from the guest physical address when it is translated through the nested page tables. The hypervisor itself does not need to be aware of which pages the guest VM marked as private. For example, a guest accessing a particular virtual address will get translated to a specific physical address with the C-bit set to 1 indicating the page should be encrypted. A specific virtual address is then used for the translation and the C-bit value from the guest physical address is saved and used on the final physical address after the nested table translation took place. | If SEV is supported and enabled, on each SEV-enabled VM, SME mode is enabled with that VM-specified encryption key. Under SEV, the {{x86|ASID}} field in the [[page table]] is used as the key index that identifies which encryption key is used to encrypt and decrypt the memory traffic associated with that VM. SEV-enabled VMs can control their own C-bit for memory pages they want encrypted. This allows those VMs to determine which pages are private (C-bit = 1) or shared (C-bit = 0). The location of that C-bit is the same location as defined under SME. It's worth noting that this control is limited to data page. In other words, memory accesses such as guest [[page tables]] and [[instruction fetches]] are always private, regardless of the value of the C-bit (i.e., in those cases the C-bit is a [[don't care]]). This was done in order to ensure that non-guest entities such as the hypervisor itself cannot inject their own code into the SEV-enabled guest VM. If the C-bit is an address bit, this bit is masked from the guest physical address when it is translated through the nested page tables. The hypervisor itself does not need to be aware of which pages the guest VM marked as private. For example, a guest accessing a particular virtual address will get translated to a specific physical address with the C-bit set to 1 indicating the page should be encrypted. A specific virtual address is then used for the translation and the C-bit value from the guest physical address is saved and used on the final physical address after the nested table translation took place. | ||
| Line 30: | Line 38: | ||
| All || {{tchk|yes}} || {{tchk|no}} || [[don't care|X]] || Optional || Host Key || Determined by page tables C-bit | | All || {{tchk|yes}} || {{tchk|no}} || [[don't care|X]] || Optional || Host Key || Determined by page tables C-bit | ||
|- | |- | ||
| − | | All || {{tchk|yes}} || {{tchk|yes}} || | + | | All || {{tchk|yes}} || {{tchk|yes}} || {{tchk|no}} || Optional || Host Key || Determined by nested page tables C-bit |
|- | |- | ||
| [[Instruction Fetch]] || {{tchk|yes}} || {{tchk|yes}} || {{tchk|yes}} || Yes || Guest Key || C-bit ignored | | [[Instruction Fetch]] || {{tchk|yes}} || {{tchk|yes}} || {{tchk|yes}} || Yes || Guest Key || C-bit ignored | ||
| Line 38: | Line 46: | ||
| Nested page table access || {{tchk|yes}} || {{tchk|yes}} || {{tchk|yes}} || Optional || Host Key || Determined by nested page tables C-bit | | Nested page table access || {{tchk|yes}} || {{tchk|yes}} || {{tchk|yes}} || Optional || Host Key || Determined by nested page tables C-bit | ||
|- | |- | ||
| − | | Data access || {{tchk|yes}} || {{tchk|yes}} || {{tchk|yes}} || Optional || Host/Guest Key || Determined by guest page tables | + | | Data access || {{tchk|yes}} || {{tchk|yes}} || {{tchk|yes}} || Optional || Host/Guest Key || Determined by guest page tables and nested page tables C-bits |
|} | |} | ||
=== Key management === | === Key management === | ||
Note that key management is actually managed by a separate processor AMD calls the {{amd|AMD Secure Processor}} or [[AMD-SP]] for short which is present on SEV-enabled chips. Therefore, while a hypervisor can manage the virtual machine keys through the AMD-SP, the actual software is unaware of the key values and cannot access them. | Note that key management is actually managed by a separate processor AMD calls the {{amd|AMD Secure Processor}} or [[AMD-SP]] for short which is present on SEV-enabled chips. Therefore, while a hypervisor can manage the virtual machine keys through the AMD-SP, the actual software is unaware of the key values and cannot access them. | ||
| + | |||
| + | == See also == | ||
| + | * {{x86|Total Memory Encryption}} | ||
| + | |||
| + | == External links == | ||
| + | * [https://developer.amd.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf White Paper: AMD MEMORY ENCRYPTION], April 21, 2016 | ||
[[Category:x86 extensions]] | [[Category:x86 extensions]] | ||
Latest revision as of 18:03, 7 May 2020
Instruction Set Architecture
- Instructions
- Addressing Modes
- Registers
- Model-Specific Register
- Assembly
- Interrupts
- Micro-Ops
- Timer
- Calling Convention
- Microarchitectures
- CPUID
Secure Memory Encryption (SME) is an x86 instruction set extension introduced by AMD for page-granular memory encryption support using a single ephemeral key. A subset of SME, Transparent SME (TSME), is a more limited form of SME used to transparently encrypt the full physical memory. Secure Encrypted Virtualization (SEV) extends SME to AMD-V, allowing individual VMs to run SME using their own secure keys.
On its Ryzen Pro processor families, AMD brands TSME as Memory Guard.
Contents
Motivation[edit]
Servers host a great deal of data including large sets of private client information. When stored in main memory in plain text, this data can be exposed to various user access attacks such as administrators scraping memory of guest data or a hypervisor bug allowing hosted guest to steal data from neighboring guest virtual machines. Furthermore, data stored in DRAM in plain text can be susceptible to physical access attacks allowing data to be stolen, especially for devices such as NVDIMMs.
The SME extension attempts to defend against those attacks by allowing the entirety of main memory to be encrypted as well as by enforcing full isolation between co-resident VMs. With the addition of SEV, this security can be extended to cloud users that can have fully private memory inaccessible to hypervisor or host software.
Overview[edit]
SME was proposed by AMD in their white paper in April 2016. SME adds the ability to mark individual pages of memory as encrypted through the page tables. Any marked page will automatically be encrypted on write and decrypted back when read by software.
Secure Memory Encryption[edit]
Secure Memory Encryption (SME) provides the ability for software to mark certain pages to be encrypted. Marked pages are automatically decrypted and encrypted upon software read and write. All pages are encrypted using a single 128-bit ephemeral AES key which is created randomly using a hardware random generator at each boot and is not accessible by software. A new key is generated by the processor on every boot.
Transparent SME[edit]
Transparent SME (TSME) as the name implies is a stricter subset of SME that requires no software intervention. Under TSME, all memory pages are encrypted regardless of the C-bit value. TSME is designed for legacy OS and hypervisor software that cannot be modified. Note that when TSME is enabled, standard SME as well as SEV are still available. TSME and SME share a memory encryption key.
Secure Encrypted Virtualization[edit]
Secure Encrypted Virtualization (SEV) is an extension of SME that effectively enables a per-virtual machine SME. In other words, SEV enables running encrypted virtual machines in which the code and data of the VM are private to the VM and may only be decrypted within the VM itself.
Mechanism[edit]
SME is typically enabled by BIOS or other firmware at boot time. This is done by setting the appropriate MSR bit to 1. Once activate, software can simply set the encryption C-bit (enCrypted) on the desired page. It's worth noting that the location of the C-bit is actually implementation-specific and must determined by making the appropriate CPUID call. Pages with a C-bit set to 1 go through the encryption engine and are stored encrypted in memory. Likewise, pages with a C-bit set to 0 go directly to memory. This means unencrypted pages do not incur any added latency because of this feature. It's worth noting that encryption I/O pages are not allowed and must have a C-bit of 0.
If SEV is supported and enabled, on each SEV-enabled VM, SME mode is enabled with that VM-specified encryption key. Under SEV, the ASID field in the page table is used as the key index that identifies which encryption key is used to encrypt and decrypt the memory traffic associated with that VM. SEV-enabled VMs can control their own C-bit for memory pages they want encrypted. This allows those VMs to determine which pages are private (C-bit = 1) or shared (C-bit = 0). The location of that C-bit is the same location as defined under SME. It's worth noting that this control is limited to data page. In other words, memory accesses such as guest page tables and instruction fetches are always private, regardless of the value of the C-bit (i.e., in those cases the C-bit is a don't care). This was done in order to ensure that non-guest entities such as the hypervisor itself cannot inject their own code into the SEV-enabled guest VM. If the C-bit is an address bit, this bit is masked from the guest physical address when it is translated through the nested page tables. The hypervisor itself does not need to be aware of which pages the guest VM marked as private. For example, a guest accessing a particular virtual address will get translated to a specific physical address with the C-bit set to 1 indicating the page should be encrypted. A specific virtual address is then used for the translation and the C-bit value from the guest physical address is saved and used on the final physical address after the nested table translation took place.
SEV may be used in conjunction with SME. Under this scenario, each SEV-enabled VM controls its own encryption via the C-bit and the host page tables control the encryption for shared memory.
| Encryption Control | ||||||
|---|---|---|---|---|---|---|
| Access Type | SME | Guest | SEV | Encrypted | Key Owner | Note |
| All | ✘ | X | X | No | N/A | SME Disabled |
| All | ✔ | ✘ | X | Optional | Host Key | Determined by page tables C-bit |
| All | ✔ | ✔ | ✘ | Optional | Host Key | Determined by nested page tables C-bit |
| Instruction Fetch | ✔ | ✔ | ✔ | Yes | Guest Key | C-bit ignored |
| Guest page table access | ✔ | ✔ | ✔ | Yes | Guest Key | C-bit ignored |
| Nested page table access | ✔ | ✔ | ✔ | Optional | Host Key | Determined by nested page tables C-bit |
| Data access | ✔ | ✔ | ✔ | Optional | Host/Guest Key | Determined by guest page tables and nested page tables C-bits |
Key management[edit]
Note that key management is actually managed by a separate processor AMD calls the AMD Secure Processor or AMD-SP for short which is present on SEV-enabled chips. Therefore, while a hypervisor can manage the virtual machine keys through the AMD-SP, the actual software is unaware of the key values and cannot access them.
See also[edit]
External links[edit]
- White Paper: AMD MEMORY ENCRYPTION, April 21, 2016