linux-kernel - Re: [PATCH, RFC 57/62] x86/mktme: Overview of Multi-Key Total Memory Encryption

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20190529072148.GE3656@rapoport-lnx>
Date:   Wed, 29 May 2019 10:21:48 +0300
From:   Mike Rapoport <rppt@...ux.ibm.com>
To:     "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>, x86@...nel.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...en8.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Andy Lutomirski <luto@...capital.net>,
        David Howells <dhowells@...hat.com>,
        Kees Cook <keescook@...omium.org>,
        Dave Hansen <dave.hansen@...el.com>,
        Kai Huang <kai.huang@...ux.intel.com>,
        Jacob Pan <jacob.jun.pan@...ux.intel.com>,
        Alison Schofield <alison.schofield@...el.com>,
        linux-mm@...ck.org, kvm@...r.kernel.org, keyrings@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH, RFC 57/62] x86/mktme: Overview of Multi-Key Total Memory
 Encryption

On Wed, May 08, 2019 at 05:44:17PM +0300, Kirill A. Shutemov wrote:
> From: Alison Schofield <alison.schofield@...el.com>
> 
> Provide an overview of MKTME on Intel Platforms.
> 
> Signed-off-by: Alison Schofield <alison.schofield@...el.com>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@...ux.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
> 

-- 
Sincerely yours,
Mike.