| Message ID | 20190508144422.13171-58-kirill.shutemov@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Intel MKTME enabling | expand |
On Wed, May 08, 2019 at 05:44:17PM +0300, Kirill A. Shutemov wrote: > From: Alison Schofield <alison.schofield@intel.com> > > Provide an overview of MKTME on Intel Platforms. > > Signed-off-by: Alison Schofield <alison.schofield@intel.com> > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > --- > Documentation/x86/mktme/index.rst | 8 +++ > Documentation/x86/mktme/mktme_overview.rst | 57 ++++++++++++++++++++++ I'd expect addition of mktme docs to Documentation/x86/index.rst > 2 files changed, 65 insertions(+) > create mode 100644 Documentation/x86/mktme/index.rst > create mode 100644 Documentation/x86/mktme/mktme_overview.rst > > diff --git a/Documentation/x86/mktme/index.rst b/Documentation/x86/mktme/index.rst > new file mode 100644 > index 000000000000..1614b52dd3e9 > --- /dev/null > +++ b/Documentation/x86/mktme/index.rst > @@ -0,0 +1,8 @@ > + > +========================================= > +Multi-Key Total Memory Encryption (MKTME) > +========================================= > + > +.. toctree:: > + > + mktme_overview > diff --git a/Documentation/x86/mktme/mktme_overview.rst b/Documentation/x86/mktme/mktme_overview.rst > new file mode 100644 > index 000000000000..59c023965554 > --- /dev/null > +++ b/Documentation/x86/mktme/mktme_overview.rst > @@ -0,0 +1,57 @@ > +Overview > +========= > +Multi-Key Total Memory Encryption (MKTME)[1] is a technology that > +allows transparent memory encryption in upcoming Intel platforms. > +It uses a new instruction (PCONFIG) for key setup and selects a > +key for individual pages by repurposing physical address bits in > +the page tables. > + > +Support for MKTME is added to the existing kernel keyring subsystem > +and via a new mprotect_encrypt() system call that can be used by > +applications to encrypt anonymous memory with keys obtained from > +the keyring. > + > +This architecture supports encrypting both normal, volatile DRAM > +and persistent memory. However, persistent memory support is > +not included in the Linux kernel implementation at this time. > +(We anticipate adding that support next.) > + > +Hardware Background > +=================== > + > +MKTME is built on top of an existing single-key technology called > +TME. TME encrypts all system memory using a single key generated > +by the CPU on every boot of the system. TME provides mitigation > +against physical attacks, such as physically removing a DIMM or > +watching memory bus traffic. > + > +MKTME enables the use of multiple encryption keys[2], allowing > +selection of the encryption key per-page using the page tables. > +Encryption keys are programmed into each memory controller and > +the same set of keys is available to all entities on the system > +with access to that memory (all cores, DMA engines, etc...). > + > +MKTME inherits many of the mitigations against hardware attacks > +from TME. Like TME, MKTME does not mitigate vulnerable or > +malicious operating systems or virtual machine managers. MKTME > +offers additional mitigations when compared to TME. > + > +TME and MKTME use the AES encryption algorithm in the AES-XTS > +mode. This mode, typically used for block-based storage devices, > +takes the physical address of the data into account when > +encrypting each block. This ensures that the effective key is > +different for each block of memory. Moving encrypted content > +across physical address results in garbage on read, mitigating > +block-relocation attacks. This property is the reason many of > +the discussed attacks require control of a shared physical page > +to be handed from the victim to the attacker. > + > +-- > +1. https://software.intel.com/sites/default/files/managed/a5/16/Multi-Key-Total-Memory-Encryption-Spec.pdf > +2. The MKTME architecture supports up to 16 bits of KeyIDs, so a > + maximum of 65535 keys on top of the “TME key” at KeyID-0. The > + first implementation is expected to support 5 bits, making 63 > + keys available to applications. However, this is not guaranteed. > + The number of available keys could be reduced if, for instance, > + additional physical address space is desired over additional > + KeyIDs. > -- > 2.20.1 >
On Wed, May 29, 2019 at 10:21:48AM +0300, Mike Rapoport wrote: > On Wed, May 08, 2019 at 05:44:17PM +0300, Kirill A. Shutemov wrote: > > From: Alison Schofield <alison.schofield@intel.com> > > > > Provide an overview of MKTME on Intel Platforms. > > > > Signed-off-by: Alison Schofield <alison.schofield@intel.com> > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > > --- > > Documentation/x86/mktme/index.rst | 8 +++ > > Documentation/x86/mktme/mktme_overview.rst | 57 ++++++++++++++++++++++ > > I'd expect addition of mktme docs to Documentation/x86/index.rst Got it. Thanks. Alison
On 5/8/19 7:44 AM, Kirill A. Shutemov wrote: > From: Alison Schofield <alison.schofield@intel.com> > > Provide an overview of MKTME on Intel Platforms. > > Signed-off-by: Alison Schofield <alison.schofield@intel.com> > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > --- > Documentation/x86/mktme/index.rst | 8 +++ > Documentation/x86/mktme/mktme_overview.rst | 57 ++++++++++++++++++++++ > 2 files changed, 65 insertions(+) > create mode 100644 Documentation/x86/mktme/index.rst > create mode 100644 Documentation/x86/mktme/mktme_overview.rst > diff --git a/Documentation/x86/mktme/mktme_overview.rst b/Documentation/x86/mktme/mktme_overview.rst > new file mode 100644 > index 000000000000..59c023965554 > --- /dev/null > +++ b/Documentation/x86/mktme/mktme_overview.rst > @@ -0,0 +1,57 @@ > +Overview > +========= ... > +-- > +1. https://software.intel.com/sites/default/files/managed/a5/16/Multi-Key-Total-Memory-Encryption-Spec.pdf > +2. The MKTME architecture supports up to 16 bits of KeyIDs, so a > + maximum of 65535 keys on top of the “TME key” at KeyID-0. The > + first implementation is expected to support 5 bits, making 63 Hi, How do 5 bits make 63 keys available? > + keys available to applications. However, this is not guaranteed. > + The number of available keys could be reduced if, for instance, > + additional physical address space is desired over additional > + KeyIDs. thanks.
On Sun, Jul 14, 2019 at 06:16:49PM +0000, Randy Dunlap wrote: > On 5/8/19 7:44 AM, Kirill A. Shutemov wrote: > > From: Alison Schofield <alison.schofield@intel.com> > > > > Provide an overview of MKTME on Intel Platforms. > > > > Signed-off-by: Alison Schofield <alison.schofield@intel.com> > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > > --- > > Documentation/x86/mktme/index.rst | 8 +++ > > Documentation/x86/mktme/mktme_overview.rst | 57 ++++++++++++++++++++++ > > 2 files changed, 65 insertions(+) > > create mode 100644 Documentation/x86/mktme/index.rst > > create mode 100644 Documentation/x86/mktme/mktme_overview.rst > > > > diff --git a/Documentation/x86/mktme/mktme_overview.rst b/Documentation/x86/mktme/mktme_overview.rst > > new file mode 100644 > > index 000000000000..59c023965554 > > --- /dev/null > > +++ b/Documentation/x86/mktme/mktme_overview.rst > > @@ -0,0 +1,57 @@ > > +Overview > > +========= > ... > > +-- > > +1. https://software.intel.com/sites/default/files/managed/a5/16/Multi-Key-Total-Memory-Encryption-Spec.pdf > > +2. The MKTME architecture supports up to 16 bits of KeyIDs, so a > > + maximum of 65535 keys on top of the “TME key” at KeyID-0. The > > + first implementation is expected to support 5 bits, making 63 > > Hi, > How do 5 bits make 63 keys available? Yep, typo. It has to be 6 bits. Alison, please correct this.
diff --git a/Documentation/x86/mktme/index.rst b/Documentation/x86/mktme/index.rst new file mode 100644 index 000000000000..1614b52dd3e9 --- /dev/null +++ b/Documentation/x86/mktme/index.rst @@ -0,0 +1,8 @@ + +========================================= +Multi-Key Total Memory Encryption (MKTME) +========================================= + +.. toctree:: + + mktme_overview diff --git a/Documentation/x86/mktme/mktme_overview.rst b/Documentation/x86/mktme/mktme_overview.rst new file mode 100644 index 000000000000..59c023965554 --- /dev/null +++ b/Documentation/x86/mktme/mktme_overview.rst @@ -0,0 +1,57 @@ +Overview +========= +Multi-Key Total Memory Encryption (MKTME)[1] is a technology that +allows transparent memory encryption in upcoming Intel platforms. +It uses a new instruction (PCONFIG) for key setup and selects a +key for individual pages by repurposing physical address bits in +the page tables. + +Support for MKTME is added to the existing kernel keyring subsystem +and via a new mprotect_encrypt() system call that can be used by +applications to encrypt anonymous memory with keys obtained from +the keyring. + +This architecture supports encrypting both normal, volatile DRAM +and persistent memory. However, persistent memory support is +not included in the Linux kernel implementation at this time. +(We anticipate adding that support next.) + +Hardware Background +=================== + +MKTME is built on top of an existing single-key technology called +TME. TME encrypts all system memory using a single key generated +by the CPU on every boot of the system. TME provides mitigation +against physical attacks, such as physically removing a DIMM or +watching memory bus traffic. + +MKTME enables the use of multiple encryption keys[2], allowing +selection of the encryption key per-page using the page tables. +Encryption keys are programmed into each memory controller and +the same set of keys is available to all entities on the system +with access to that memory (all cores, DMA engines, etc...). + +MKTME inherits many of the mitigations against hardware attacks +from TME. Like TME, MKTME does not mitigate vulnerable or +malicious operating systems or virtual machine managers. MKTME +offers additional mitigations when compared to TME. + +TME and MKTME use the AES encryption algorithm in the AES-XTS +mode. This mode, typically used for block-based storage devices, +takes the physical address of the data into account when +encrypting each block. This ensures that the effective key is +different for each block of memory. Moving encrypted content +across physical address results in garbage on read, mitigating +block-relocation attacks. This property is the reason many of +the discussed attacks require control of a shared physical page +to be handed from the victim to the attacker. + +-- +1. https://software.intel.com/sites/default/files/managed/a5/16/Multi-Key-Total-Memory-Encryption-Spec.pdf +2. The MKTME architecture supports up to 16 bits of KeyIDs, so a + maximum of 65535 keys on top of the “TME key” at KeyID-0. The + first implementation is expected to support 5 bits, making 63 + keys available to applications. However, this is not guaranteed. + The number of available keys could be reduced if, for instance, + additional physical address space is desired over additional + KeyIDs.