From WikiChip
Difference between revisions of "x86/tme"
< x86

(Mechanism: example)
 
(9 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
{{x86 title|Total Memory Encryption (TME)}}{{x86 isa main}}
 
{{x86 title|Total Memory Encryption (TME)}}{{x86 isa main}}
'''Total Memory Encryption''' ('''TME''') is a planned [[x86]] [[instruction set]] extension for a full physical memory encryption for [[DRAM]] and [[NVRAM]] with a single ephemeral key. '''Multi-Key Total Memory Encryption''' ('''MKTME''') refers to an enhanced support that builds on top of TME and adds multiple encryption keys.
+
'''Total Memory Encryption''' ('''TME''') is a planned [[x86]] [[instruction set]] {{x86|extension}} proposed by [[Intel]] for a full physical memory encryption for [[DRAM]] and [[NVRAM]] with a single ephemeral key. TME can be further extended with the '''Multi-Key Total Memory Encryption''' ('''MKTME''') extension which builds on TME and adds support multiple encryption keys.
  
  
Line 7: Line 7:
  
 
== Overview ==
 
== Overview ==
TME and MKTME are a planned [[x86]] instruction set {{x86|extension}} that provides full physical memory encryption support for [[DRAM]] and [[NVRAM]]. TME is the base extension which adds the base capabilities for a single ephemeral key. MKTME is a further enhancement of TME that provides support for page granular memory encryption through support for multiple encryption keys. Those capabilities are exposed to software via {{x86|model-specific registers}}.
+
Proposed by [[Intel]] in late [[2017]], TME and MKTME are a planned [[x86]] instruction set {{x86|extension}} that provides full physical memory encryption support for [[DRAM]] and [[NVRAM]]. TME is the base extension which adds the base capabilities for a single ephemeral key. MKTME is a further enhancement of TME that provides support for page-granular memory encryption through support for multiple encryption keys. Those capabilities are exposed to software via {{x86|model-specific registers}}.
  
 
Inside the chip itself (e.g., [[registers]] and [[caches]]) the data remains in plain text. This is done in order to maintain compatibility with all existing software and I/O models. An [[AES-XTS]] encryption engine is physically located directly on the data paths to external memory buses ensuring all data entering and leaving the chip is encrypted. Note that there is one exception for a specially defined [[#Exclusion range|exclusion range]].
 
Inside the chip itself (e.g., [[registers]] and [[caches]]) the data remains in plain text. This is done in order to maintain compatibility with all existing software and I/O models. An [[AES-XTS]] encryption engine is physically located directly on the data paths to external memory buses ensuring all data entering and leaving the chip is encrypted. Note that there is one exception for a specially defined [[#Exclusion range|exclusion range]].
Line 13: Line 13:
  
 
:[[File:x86 tme.svg|450px]]
 
:[[File:x86 tme.svg|450px]]
 +
 +
 +
=== Supported Modes ===
 +
The specification currently only uses bit 0 for [[AES-XTS]] and reserves additional bits. Therefore support for additional encryption scheme is possible in the future.
  
 
== Total Memory Encryption  ==
 
== Total Memory Encryption  ==
The '''Total Memory Encryption''' ('''TME''') provides the base functionality to allow for full physical memory encryption. The extension is designed to work with unmodified existing software applications and systems. This feature is enabled via the BIOS during the initial boot process with very minor modifications. Once activated, all data sent on the external memory buses of the chip are encrypted using the standard NIST [[AES-XTS]] algorithm. It's worth noting that the specification currently only uses bit 0 for AES-XTS and reserves additional bits. Therefore support for additional encryption scheme is possible in the future.  The implementation uses a [[hardware random generator]] to generate the 128-bit key and is not accessible by software or through any external interface. A new platform key is generated by the processor on every boot.
+
The '''Total Memory Encryption''' ('''TME''') provides the base functionality to allow for full physical memory encryption. The extension is designed to work with unmodified existing software applications and systems. This feature is enabled via the BIOS during the initial boot process with very minor modifications. Once activated, all data sent on the external memory buses of the chip are encrypted using the standard NIST [[AES-XTS]] algorithm. The implementation uses a [[hardware random generator]] to generate the 128-bit key and is not accessible by software or through any external interface. A new platform key is generated by the processor on every boot.
  
 
== Multi-Key Total Memory Encryption ==
 
== Multi-Key Total Memory Encryption ==
Line 25: Line 29:
  
 
== Mechanism ==
 
== Mechanism ==
 +
[[File:x86 tme physical address changes.svg|right|500px]]
 
TME is typically enabled by [[BIOS]] or other [[firmware]] at boot time. This is done via a new <code>{{x86|IA32_TME_ACTIVATE}}</code> {{x86|MSR}}. Note MKTME is an extension of TME, therefore in order for MKTME to work TME must be enabled. <code>KeyID 0</code> is reserved for TME and is generated by a [[hardware random generator]] at every boot time. That key is always available and is inaccessible to software. If the system is resuming from a standby TME can restore the key from storage.
 
TME is typically enabled by [[BIOS]] or other [[firmware]] at boot time. This is done via a new <code>{{x86|IA32_TME_ACTIVATE}}</code> {{x86|MSR}}. Note MKTME is an extension of TME, therefore in order for MKTME to work TME must be enabled. <code>KeyID 0</code> is reserved for TME and is generated by a [[hardware random generator]] at every boot time. That key is always available and is inaccessible to software. If the system is resuming from a standby TME can restore the key from storage.
  
KeyIDs is a very important part of TME and MKTME. It's incorporated into the physical address, meaning it's just in the page tables, but also in every other storage location such as the [[caches]] and [[TLBs]]. <code>KeyID 0</code> is reserved for TME and for a system-wide encryption, additional keys are provided by the MKTME extension.
+
KeyIDs is a very important part of TME and MKTME. It's incorporated into the physical address, meaning it's not just in the page tables, but also in every other storage location such as the [[caches]] and [[TLBs]]. <code>KeyID 0</code> is reserved for TME and for a system-wide encryption, additional keys are provided by the MKTME extension.
  
 
If MKTME is also support, it can be be enabled also using the <code>{{x86|IA32_TME_ACTIVATE}}</code> {{x86|MSR}} by setting the number of KeyID bits to configure (in theory up to 32K-1 keys). Once MKTME is enabled, the processor will re-purpose the physical address bits in order to communicate the KeyID to the encryption engines. Internally, the MKTME engine maintains an internal table used to hold keys and encryption modes (i.e., key specified, KeyID 0 (TME), and do not encrypt) which are associated with each KeyID. Those attributes can be programmed using the <code>PCONFIG</code> instruction.
 
If MKTME is also support, it can be be enabled also using the <code>{{x86|IA32_TME_ACTIVATE}}</code> {{x86|MSR}} by setting the number of KeyID bits to configure (in theory up to 32K-1 keys). Once MKTME is enabled, the processor will re-purpose the physical address bits in order to communicate the KeyID to the encryption engines. Internally, the MKTME engine maintains an internal table used to hold keys and encryption modes (i.e., key specified, KeyID 0 (TME), and do not encrypt) which are associated with each KeyID. Those attributes can be programmed using the <code>PCONFIG</code> instruction.
 
::[[File:x86 tme physical address changes.svg|500px]]
 
  
 
=== Example ===
 
=== Example ===
Line 45: Line 48:
 
== Performance ==
 
== Performance ==
 
The exact performance impact will greatly depend on the workload, but overall the performance impact should be minimal.
 
The exact performance impact will greatly depend on the workload, but overall the performance impact should be minimal.
 +
 +
== See also ==
 +
* {{x86|Secure Memory Encryption}}
 +
 +
== External links ==
 +
* [https://software.intel.com/sites/default/files/managed/a5/16/Multi-Key-Total-Memory-Encryption-Spec.pdf Intel Memory Encryption Technologies, External Architecture Specification], Rev Number: 1.0
 +
 +
 +
[[Category:x86 extensions]]

Latest revision as of 02:40, 17 December 2017

Total Memory Encryption (TME) is a planned x86 instruction set extension proposed by Intel for a full physical memory encryption for DRAM and NVRAM with a single ephemeral key. TME can be further extended with the Multi-Key Total Memory Encryption (MKTME) extension which builds on TME and adds support multiple encryption keys.


Symbol version future.svg Preliminary Data! Information presented in this article deal with future products, data, features, and specifications that have yet to be finalized, announced, or released. Information may be incomplete and can change by final release.


Overview[edit]

Proposed by Intel in late 2017, TME and MKTME are a planned x86 instruction set extension that provides full physical memory encryption support for DRAM and NVRAM. TME is the base extension which adds the base capabilities for a single ephemeral key. MKTME is a further enhancement of TME that provides support for page-granular memory encryption through support for multiple encryption keys. Those capabilities are exposed to software via model-specific registers.

Inside the chip itself (e.g., registers and caches) the data remains in plain text. This is done in order to maintain compatibility with all existing software and I/O models. An AES-XTS encryption engine is physically located directly on the data paths to external memory buses ensuring all data entering and leaving the chip is encrypted. Note that there is one exception for a specially defined exclusion range.


x86 tme.svg


Supported Modes[edit]

The specification currently only uses bit 0 for AES-XTS and reserves additional bits. Therefore support for additional encryption scheme is possible in the future.

Total Memory Encryption[edit]

The Total Memory Encryption (TME) provides the base functionality to allow for full physical memory encryption. The extension is designed to work with unmodified existing software applications and systems. This feature is enabled via the BIOS during the initial boot process with very minor modifications. Once activated, all data sent on the external memory buses of the chip are encrypted using the standard NIST AES-XTS algorithm. The implementation uses a hardware random generator to generate the 128-bit key and is not accessible by software or through any external interface. A new platform key is generated by the processor on every boot.

Multi-Key Total Memory Encryption[edit]

Multi-Key Total Memory Encryption (MKTME) is an extension of TME that adds support for multiple keys, therefore TME must be enabled in order to make use of MKTME. A fixed number of encryption keys are supported. Software can then configure the chip to use any subset of the available keys to encrypt any page of the memory. This functionality is available on a per-page basis.

Unless otherwise specified by software, MKTME uses the hardware-generated ephemeral key by default which is inaccessible by software or external interfaces. Alternatively, MKTME also supports software-provided keys. This mean MKTME can effectively work with non-volatile memory, various attestation mechanisms, or other key provisioning services. For virtualized workloads, a hypervisor can manage the keys to transparently provide memory encryption support for legacy operating systems without any modifications.

Note that operating systems can also take advantage of MKTME to provide support in native and virtualized environment. For example, each guest OS in a virtualized environment can take advantage of MKTME for itself and encrypt its own data.

Mechanism[edit]

x86 tme physical address changes.svg

TME is typically enabled by BIOS or other firmware at boot time. This is done via a new IA32_TME_ACTIVATE MSR. Note MKTME is an extension of TME, therefore in order for MKTME to work TME must be enabled. KeyID 0 is reserved for TME and is generated by a hardware random generator at every boot time. That key is always available and is inaccessible to software. If the system is resuming from a standby TME can restore the key from storage.

KeyIDs is a very important part of TME and MKTME. It's incorporated into the physical address, meaning it's not just in the page tables, but also in every other storage location such as the caches and TLBs. KeyID 0 is reserved for TME and for a system-wide encryption, additional keys are provided by the MKTME extension.

If MKTME is also support, it can be be enabled also using the IA32_TME_ACTIVATE MSR by setting the number of KeyID bits to configure (in theory up to 32K-1 keys). Once MKTME is enabled, the processor will re-purpose the physical address bits in order to communicate the KeyID to the encryption engines. Internally, the MKTME engine maintains an internal table used to hold keys and encryption modes (i.e., key specified, KeyID 0 (TME), and do not encrypt) which are associated with each KeyID. Those attributes can be programmed using the PCONFIG instruction.

Example[edit]

x86 tme virtualization example venn diagram.svg

Consider a system with a hypervisor that is managing two virtual machines.

x86 tme virtualization example.svg

In this example, for shared memory, all three processes use KeyID 0 (same as TME). For its own memory, the hypervisor also uses KeyID 1 for its own encrypted memory. VM0 and VM1 can also use KeyID 0 (TME KeyID) for any page. VM0 also uses KeyID 3 for its own private pages and VM1 uses KeyID 4 for its own. Both VM0 and VM1 can also opt to use KeyID 2 for shared memory.

Exclusion range[edit]

A single exclusion range is supported (for both TME/MKTME for KeyID 0 only) for special use cases such as BIOS memory ranges that are not generally available to the operating system. Once the physical addresses are set, no memory encryption is applied to this range.

Performance[edit]

The exact performance impact will greatly depend on the workload, but overall the performance impact should be minimal.

See also[edit]

External links[edit]