From: Mike Rapoport <rppt@linux.ibm.com>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Borislav Petkov <bp@alien8.de>,
Peter Zijlstra <peterz@infradead.org>,
Andy Lutomirski <luto@amacapital.net>,
David Howells <dhowells@redhat.com>,
Kees Cook <keescook@chromium.org>,
Dave Hansen <dave.hansen@intel.com>,
Kai Huang <kai.huang@linux.intel.com>,
Jacob Pan <jacob.jun.pan@linux.intel.com>,
Alison Schofield <alison.schofield@intel.com>,
linux-mm@kvack.org, kvm@vger.kernel.org,
keyrings@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH, RFC 00/62] Intel MKTME enabling
Date: Wed, 29 May 2019 10:30:07 +0300 [thread overview]
Message-ID: <20190529073006.GG3656@rapoport-lnx> (raw)
In-Reply-To: <20190508144422.13171-1-kirill.shutemov@linux.intel.com>
On Wed, May 08, 2019 at 05:43:20PM +0300, Kirill A. Shutemov wrote:
> = Intro =
>
> The patchset brings enabling of Intel Multi-Key Total Memory Encryption.
> It consists of changes into multiple subsystems:
>
> * Core MM: infrastructure for allocation pages, dealing with encrypted VMAs
> and providing API setup encrypted mappings.
> * arch/x86: feature enumeration, program keys into hardware, setup
> page table entries for encrypted pages and more.
> * Key management service: setup and management of encryption keys.
> * DMA/IOMMU: dealing with encrypted memory on IO side.
> * KVM: interaction with virtualization side.
> * Documentation: description of APIs and usage examples.
>
> The patchset is huge. This submission aims to give view to the full picture and
> get feedback on the overall design. The patchset will be split into more
> digestible pieces later.
>
> Please review. Any feedback is welcome.
It would be nice to have a brief usage description in cover letter rather
than in the last patches in the series ;-)
> = 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.
>
> These patches add support for MKTME into the existing kernel keyring subsystem
> and add 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, these patches do not implement persistent memory support. 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.
>
> == MKTME-Provided Mitigations ==
>
> MKTME adds a few mitigations against attacks that are not mitigated when using
> TME alone. The first set are mitigations against software attacks that are
> familiar today:
>
> * Kernel Mapping Attacks: information disclosures that leverage the
> kernel direct map are mitigated against disclosing user data.
> * Freed Data Leak Attacks: removing an encryption key from the
> hardware mitigates future user information disclosure.
>
> The next set are attacks that depend on specialized hardware, such as an “evil
> DIMM” or a DDR interposer:
>
> * Cross-Domain Replay Attack: data is captured from one domain
> (guest) and replayed to another at a later time.
> * Cross-Domain Capture and Delayed Compare Attack: data is captured
> and later analyzed to discover secrets.
> * Key Wear-out Attack: data is captured and analyzed in order to
> Weaken the AES encryption itself.
>
> More details on these attacks are below.
>
> === Kernel Mapping Attacks ===
>
> Information disclosure vulnerabilities leverage the kernel direct map because
> many vulnerabilities involve manipulation of kernel data structures (examples:
> CVE-2017-7277, CVE-2017-9605). We normally think of these bugs as leaking
> valuable *kernel* data, but they can leak application data when application
> pages are recycled for kernel use.
>
> With this MKTME implementation, there is a direct map created for each MKTME
> KeyID which is used whenever the kernel needs to access plaintext. But, all
> kernel data structures are accessed via the direct map for KeyID-0. Thus,
> memory reads which are not coordinated with the KeyID get garbage (for example,
> accessing KeyID-4 data with the KeyID-0 mapping).
>
> This means that if sensitive data encrypted using MKTME is leaked via the
> KeyID-0 direct map, ciphertext decrypted with the wrong key will be disclosed.
> To disclose plaintext, an attacker must “pivot” to the correct direct mapping,
> which is non-trivial because there are no kernel data structures in the
> KeyID!=0 direct mapping.
>
> === Freed Data Leak Attack ===
>
> The kernel has a history of bugs around uninitialized data. Usually, we think
> of these bugs as leaking sensitive kernel data, but they can also be used to
> leak application secrets.
>
> MKTME can help mitigate the case where application secrets are leaked:
>
> * App (or VM) places a secret in a page
> * App exits or frees memory to kernel allocator
> * Page added to allocator free list
> * Attacker reallocates page to a purpose where it can read the page
>
> Now, imagine MKTME was in use on the memory being leaked. The data can only be
> leaked as long as the key is programmed in the hardware. If the key is
> de-programmed, like after all pages are freed after a guest is shut down, any
> future reads will just see ciphertext.
>
> Basically, the key is a convenient choke-point: you can be more confident that
> data encrypted with it is inaccessible once the key is removed.
>
> === Cross-Domain Replay Attack ===
>
> MKTME mitigates cross-domain replay attacks where an attacker replaces an
> encrypted block owned by one domain with a block owned by another domain.
> MKTME does not prevent this replacement from occurring, but it does mitigate
> plaintext from being disclosed if the domains use different keys.
>
> With TME, the attack could be executed by:
> * A victim places secret in memory, at a given physical address.
> Note: AES-XTS is what restricts the attack to being performed at a
> single physical address instead of across different physical
> addresses
> * Attacker captures victim secret’s ciphertext
> * Later on, after victim frees the physical address, attacker gains
> ownership
> * Attacker puts the ciphertext at the address and get the secret
> plaintext
>
> But, due to the presumably different keys used by the attacker and the victim,
> the attacker can not successfully decrypt old ciphertext.
>
> === Cross-Domain Capture and Delayed Compare Attack ===
>
> This is also referred to as a kind of dictionary attack.
>
> Similarly, MKTME protects against cross-domain capture-and-compare attacks.
> Consider the following scenario:
> * A victim places a secret in memory, at a known physical address
> * Attacker captures victim’s ciphertext
> * Attacker gains control of the target physical address, perhaps
> after the victim’s VM is shut down or its memory reclaimed.
> * Attacker computes and writes many possible plaintexts until new
> ciphertext matches content captured previously.
>
> Secrets which have low (plaintext) entropy are more vulnerable to this attack
> because they reduce the number of possible plaintexts an attacker has to
> compute and write.
>
> The attack will not work if attacker and victim uses different keys.
>
> === Key Wear-out Attack ===
>
> Repeated use of an encryption key might be used by an attacker to infer
> information about the key or the plaintext, weakening the encryption. The
> higher the bandwidth of the encryption engine, the more vulnerable the key is
> to wear-out. The MKTME memory encryption hardware works at the speed of the
> memory bus, which has high bandwidth.
>
> Such a weakness has been demonstrated[3] on a theoretical cipher with similar
> properties as AES-XTS.
>
> An attack would take the following steps:
> * Victim system is using TME with AES-XTS-128
> * Attacker repeatedly captures ciphertext/plaintext pairs (can be
> Performed with online hardware attack like an interposer).
> * Attacker compels repeated use of the key under attack for a
> sustained time period without a system reboot[4].
> * Attacker discovers a cipertext collision (two plaintexts
> translating to the same ciphertext)
> * Attacker can induce controlled modifications to the targeted
> plaintext by modifying the colliding ciphertext
>
> MKTME mitigates key wear-out in two ways:
> * Keys can be rotated periodically to mitigate wear-out. Since TME
> keys are generated at boot, rotation of TME keys requires a
> reboot. In contrast, MKTME allows rotation while the system is
> booted. An application could implement a policy to rotate keys at
> a frequency which is not feasible to attack.
> * In the case that MKTME is used to encrypt two guests’ memory with
> two different keys, an attack on one guest’s key would not weaken
> the key used in the second guest.
>
> --
>
> [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.
> [3] http://web.cs.ucdavis.edu/~rogaway/papers/offsets.pdf
> [4] This sustained time required for an attack could vary from days
> to years depending on the attacker’s goals.
>
> Alison Schofield (33):
> x86/pconfig: Set a valid encryption algorithm for all MKTME commands
> keys/mktme: Introduce a Kernel Key Service for MKTME
> keys/mktme: Preparse the MKTME key payload
> keys/mktme: Instantiate and destroy MKTME keys
> keys/mktme: Move the MKTME payload into a cache aligned structure
> keys/mktme: Strengthen the entropy of CPU generated MKTME keys
> keys/mktme: Set up PCONFIG programming targets for MKTME keys
> keys/mktme: Program MKTME keys into the platform hardware
> keys/mktme: Set up a percpu_ref_count for MKTME keys
> keys/mktme: Require CAP_SYS_RESOURCE capability for MKTME keys
> keys/mktme: Store MKTME payloads if cmdline parameter allows
> acpi: Remove __init from acpi table parsing functions
> acpi/hmat: Determine existence of an ACPI HMAT
> keys/mktme: Require ACPI HMAT to register the MKTME Key Service
> acpi/hmat: Evaluate topology presented in ACPI HMAT for MKTME
> keys/mktme: Do not allow key creation in unsafe topologies
> keys/mktme: Support CPU hotplug for MKTME key service
> keys/mktme: Find new PCONFIG targets during memory hotplug
> keys/mktme: Program new PCONFIG targets with MKTME keys
> keys/mktme: Support memory hotplug for MKTME keys
> mm: Generalize the mprotect implementation to support extensions
> syscall/x86: Wire up a system call for MKTME encryption keys
> x86/mm: Set KeyIDs in encrypted VMAs for MKTME
> mm: Add the encrypt_mprotect() system call for MKTME
> x86/mm: Keep reference counts on encrypted VMAs for MKTME
> mm: Restrict MKTME memory encryption to anonymous VMAs
> selftests/x86/mktme: Test the MKTME APIs
> x86/mktme: Overview of Multi-Key Total Memory Encryption
> x86/mktme: Document the MKTME provided security mitigations
> x86/mktme: Document the MKTME kernel configuration requirements
> x86/mktme: Document the MKTME Key Service API
> x86/mktme: Document the MKTME API for anonymous memory encryption
> x86/mktme: Demonstration program using the MKTME APIs
>
> Jacob Pan (3):
> iommu/vt-d: Support MKTME in DMA remapping
> x86/mm: introduce common code for mem encryption
> x86/mm: Use common code for DMA memory encryption
>
> Kai Huang (2):
> mm, x86: export several MKTME variables
> kvm, x86, mmu: setup MKTME keyID to spte for given PFN
>
> Kirill A. Shutemov (24):
> mm: Do no merge VMAs with different encryption KeyIDs
> mm: Add helpers to setup zero page mappings
> mm/ksm: Do not merge pages with different KeyIDs
> mm/page_alloc: Unify alloc_hugepage_vma()
> mm/page_alloc: Handle allocation for encrypted memory
> mm/khugepaged: Handle encrypted pages
> x86/mm: Mask out KeyID bits from page table entry pfn
> x86/mm: Introduce variables to store number, shift and mask of KeyIDs
> x86/mm: Preserve KeyID on pte_modify() and pgprot_modify()
> x86/mm: Detect MKTME early
> x86/mm: Add a helper to retrieve KeyID for a page
> x86/mm: Add a helper to retrieve KeyID for a VMA
> x86/mm: Add hooks to allocate and free encrypted pages
> x86/mm: Map zero pages into encrypted mappings correctly
> x86/mm: Rename CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING
> x86/mm: Allow to disable MKTME after enumeration
> x86/mm: Calculate direct mapping size
> x86/mm: Implement syncing per-KeyID direct mappings
> x86/mm: Handle encrypted memory in page_to_virt() and __pa()
> mm/page_ext: Export lookup_page_ext() symbol
> mm/rmap: Clear vma->anon_vma on unlink_anon_vmas()
> x86/mm: Disable MKTME on incompatible platform configurations
> x86/mm: Disable MKTME if not all system memory supports encryption
> x86: Introduce CONFIG_X86_INTEL_MKTME
>
> .../admin-guide/kernel-parameters.rst | 1 +
> .../admin-guide/kernel-parameters.txt | 11 +
> Documentation/x86/mktme/index.rst | 13 +
> .../x86/mktme/mktme_configuration.rst | 17 +
> Documentation/x86/mktme/mktme_demo.rst | 53 ++
> Documentation/x86/mktme/mktme_encrypt.rst | 57 ++
> Documentation/x86/mktme/mktme_keys.rst | 96 +++
> Documentation/x86/mktme/mktme_mitigations.rst | 150 ++++
> Documentation/x86/mktme/mktme_overview.rst | 57 ++
> Documentation/x86/x86_64/mm.txt | 4 +
> arch/alpha/include/asm/page.h | 2 +-
> arch/x86/Kconfig | 29 +-
> arch/x86/entry/syscalls/syscall_32.tbl | 1 +
> arch/x86/entry/syscalls/syscall_64.tbl | 1 +
> arch/x86/include/asm/intel-family.h | 2 +
> arch/x86/include/asm/intel_pconfig.h | 14 +-
> arch/x86/include/asm/mem_encrypt.h | 29 +
> arch/x86/include/asm/mktme.h | 93 +++
> arch/x86/include/asm/page.h | 4 +
> arch/x86/include/asm/page_32.h | 1 +
> arch/x86/include/asm/page_64.h | 4 +-
> arch/x86/include/asm/pgtable.h | 19 +
> arch/x86/include/asm/pgtable_types.h | 23 +-
> arch/x86/include/asm/setup.h | 6 +
> arch/x86/kernel/cpu/intel.c | 58 +-
> arch/x86/kernel/head64.c | 4 +
> arch/x86/kernel/setup.c | 3 +
> arch/x86/kvm/mmu.c | 18 +-
> arch/x86/mm/Makefile | 3 +
> arch/x86/mm/init_64.c | 68 ++
> arch/x86/mm/kaslr.c | 11 +-
> arch/x86/mm/mem_encrypt_common.c | 28 +
> arch/x86/mm/mktme.c | 630 ++++++++++++++
> drivers/acpi/hmat/hmat.c | 67 ++
> drivers/acpi/tables.c | 10 +-
> drivers/firmware/efi/efi.c | 25 +-
> drivers/iommu/intel-iommu.c | 29 +-
> fs/dax.c | 3 +-
> fs/exec.c | 4 +-
> fs/userfaultfd.c | 7 +-
> include/asm-generic/pgtable.h | 8 +
> include/keys/mktme-type.h | 39 +
> include/linux/acpi.h | 9 +-
> include/linux/dma-direct.h | 4 +-
> include/linux/efi.h | 1 +
> include/linux/gfp.h | 51 +-
> include/linux/intel-iommu.h | 9 +-
> include/linux/mem_encrypt.h | 23 +-
> include/linux/migrate.h | 14 +-
> include/linux/mm.h | 27 +-
> include/linux/page_ext.h | 11 +-
> include/linux/syscalls.h | 2 +
> include/uapi/asm-generic/unistd.h | 4 +-
> kernel/fork.c | 2 +
> kernel/sys_ni.c | 2 +
> mm/compaction.c | 3 +
> mm/huge_memory.c | 6 +-
> mm/khugepaged.c | 10 +
> mm/ksm.c | 17 +
> mm/madvise.c | 2 +-
> mm/memory.c | 3 +-
> mm/mempolicy.c | 30 +-
> mm/migrate.c | 4 +-
> mm/mlock.c | 2 +-
> mm/mmap.c | 31 +-
> mm/mprotect.c | 98 ++-
> mm/page_alloc.c | 50 ++
> mm/page_ext.c | 5 +
> mm/rmap.c | 4 +-
> mm/userfaultfd.c | 3 +-
> security/keys/Makefile | 1 +
> security/keys/mktme_keys.c | 768 ++++++++++++++++++
> .../selftests/x86/mktme/encrypt_tests.c | 433 ++++++++++
> .../testing/selftests/x86/mktme/flow_tests.c | 266 ++++++
> tools/testing/selftests/x86/mktme/key_tests.c | 526 ++++++++++++
> .../testing/selftests/x86/mktme/mktme_test.c | 300 +++++++
> 76 files changed, 4301 insertions(+), 122 deletions(-)
> create mode 100644 Documentation/x86/mktme/index.rst
> create mode 100644 Documentation/x86/mktme/mktme_configuration.rst
> create mode 100644 Documentation/x86/mktme/mktme_demo.rst
> create mode 100644 Documentation/x86/mktme/mktme_encrypt.rst
> create mode 100644 Documentation/x86/mktme/mktme_keys.rst
> create mode 100644 Documentation/x86/mktme/mktme_mitigations.rst
> create mode 100644 Documentation/x86/mktme/mktme_overview.rst
> create mode 100644 arch/x86/include/asm/mktme.h
> create mode 100644 arch/x86/mm/mem_encrypt_common.c
> create mode 100644 arch/x86/mm/mktme.c
> create mode 100644 include/keys/mktme-type.h
> create mode 100644 security/keys/mktme_keys.c
> create mode 100644 tools/testing/selftests/x86/mktme/encrypt_tests.c
> create mode 100644 tools/testing/selftests/x86/mktme/flow_tests.c
> create mode 100644 tools/testing/selftests/x86/mktme/key_tests.c
> create mode 100644 tools/testing/selftests/x86/mktme/mktme_test.c
>
> --
> 2.20.1
>
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2019-05-29 7:31 UTC|newest]
Thread overview: 153+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-08 14:43 [PATCH, RFC 00/62] Intel MKTME enabling Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 01/62] mm: Do no merge VMAs with different encryption KeyIDs Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 02/62] mm: Add helpers to setup zero page mappings Kirill A. Shutemov
2019-05-29 7:21 ` Mike Rapoport
2019-05-08 14:43 ` [PATCH, RFC 03/62] mm/ksm: Do not merge pages with different KeyIDs Kirill A. Shutemov
2019-05-10 18:07 ` Dave Hansen
2019-05-13 14:27 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 04/62] mm/page_alloc: Unify alloc_hugepage_vma() Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 05/62] mm/page_alloc: Handle allocation for encrypted memory Kirill A. Shutemov
2019-05-29 7:21 ` Mike Rapoport
2019-05-29 12:47 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 06/62] mm/khugepaged: Handle encrypted pages Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 07/62] x86/mm: Mask out KeyID bits from page table entry pfn Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 08/62] x86/mm: Introduce variables to store number, shift and mask of KeyIDs Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 09/62] x86/mm: Preserve KeyID on pte_modify() and pgprot_modify() Kirill A. Shutemov
2019-06-14 9:15 ` Peter Zijlstra
2019-06-14 13:03 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 10/62] x86/mm: Detect MKTME early Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 11/62] x86/mm: Add a helper to retrieve KeyID for a page Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 12/62] x86/mm: Add a helper to retrieve KeyID for a VMA Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 13/62] x86/mm: Add hooks to allocate and free encrypted pages Kirill A. Shutemov
2019-06-14 9:34 ` Peter Zijlstra
2019-06-14 11:04 ` Peter Zijlstra
2019-06-14 13:28 ` Kirill A. Shutemov
2019-06-14 13:43 ` Peter Zijlstra
2019-06-14 22:41 ` Kirill A. Shutemov
2019-06-17 9:25 ` Peter Zijlstra
2019-06-14 13:14 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 14/62] x86/mm: Map zero pages into encrypted mappings correctly Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 15/62] x86/mm: Rename CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 16/62] x86/mm: Allow to disable MKTME after enumeration Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 17/62] x86/mm: Calculate direct mapping size Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 18/62] x86/mm: Implement syncing per-KeyID direct mappings Kirill A. Shutemov
2019-06-14 9:51 ` Peter Zijlstra
2019-06-14 22:43 ` Kirill A. Shutemov
2019-06-17 9:27 ` Peter Zijlstra
2019-06-17 14:43 ` Kirill A. Shutemov
2019-06-17 14:51 ` Peter Zijlstra
2019-06-17 15:17 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 19/62] x86/mm: Handle encrypted memory in page_to_virt() and __pa() Kirill A. Shutemov
2019-06-14 11:10 ` Peter Zijlstra
2019-05-08 14:43 ` [PATCH, RFC 20/62] mm/page_ext: Export lookup_page_ext() symbol Kirill A. Shutemov
2019-06-14 11:12 ` Peter Zijlstra
2019-06-14 22:44 ` Kirill A. Shutemov
2019-06-17 9:30 ` Peter Zijlstra
2019-06-17 11:01 ` Kai Huang
2019-06-17 11:13 ` Huang, Kai
2019-05-08 14:43 ` [PATCH, RFC 21/62] mm/rmap: Clear vma->anon_vma on unlink_anon_vmas() Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 22/62] x86/pconfig: Set a valid encryption algorithm for all MKTME commands Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 23/62] keys/mktme: Introduce a Kernel Key Service for MKTME Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 24/62] keys/mktme: Preparse the MKTME key payload Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 25/62] keys/mktme: Instantiate and destroy MKTME keys Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 26/62] keys/mktme: Move the MKTME payload into a cache aligned structure Kirill A. Shutemov
2019-06-14 11:35 ` Peter Zijlstra
2019-06-14 17:10 ` Alison Schofield
2019-05-08 14:43 ` [PATCH, RFC 27/62] keys/mktme: Strengthen the entropy of CPU generated MKTME keys Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 28/62] keys/mktme: Set up PCONFIG programming targets for " Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 29/62] keys/mktme: Program MKTME keys into the platform hardware Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 30/62] keys/mktme: Set up a percpu_ref_count for MKTME keys Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 31/62] keys/mktme: Require CAP_SYS_RESOURCE capability " Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 32/62] keys/mktme: Store MKTME payloads if cmdline parameter allows Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 33/62] acpi: Remove __init from acpi table parsing functions Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 34/62] acpi/hmat: Determine existence of an ACPI HMAT Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 35/62] keys/mktme: Require ACPI HMAT to register the MKTME Key Service Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 36/62] acpi/hmat: Evaluate topology presented in ACPI HMAT for MKTME Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 37/62] keys/mktme: Do not allow key creation in unsafe topologies Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 38/62] keys/mktme: Support CPU hotplug for MKTME key service Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 39/62] keys/mktme: Find new PCONFIG targets during memory hotplug Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 40/62] keys/mktme: Program new PCONFIG targets with MKTME keys Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 41/62] keys/mktme: Support memory hotplug for " Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 42/62] mm: Generalize the mprotect implementation to support extensions Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 43/62] syscall/x86: Wire up a system call for MKTME encryption keys Kirill A. Shutemov
2019-05-29 7:21 ` Mike Rapoport
2019-05-29 18:12 ` Alison Schofield
2019-05-08 14:44 ` [PATCH, RFC 44/62] x86/mm: Set KeyIDs in encrypted VMAs for MKTME Kirill A. Shutemov
2019-06-14 11:44 ` Peter Zijlstra
2019-06-14 17:33 ` Alison Schofield
2019-06-14 18:26 ` Dave Hansen
2019-06-14 18:46 ` Alison Schofield
2019-06-14 19:11 ` Dave Hansen
2019-06-17 9:10 ` Peter Zijlstra
2019-05-08 14:44 ` [PATCH, RFC 45/62] mm: Add the encrypt_mprotect() system call " Kirill A. Shutemov
2019-06-14 11:47 ` Peter Zijlstra
2019-06-14 17:35 ` Alison Schofield
2019-06-14 11:51 ` Peter Zijlstra
2019-06-15 0:32 ` Alison Schofield
2019-06-17 9:08 ` Peter Zijlstra
2019-06-17 15:07 ` Andy Lutomirski
2019-06-17 15:28 ` Dave Hansen
2019-06-17 15:46 ` Andy Lutomirski
2019-06-17 18:27 ` Dave Hansen
2019-06-17 19:12 ` Andy Lutomirski
2019-06-17 21:36 ` Dave Hansen
2019-06-18 0:48 ` Kai Huang
2019-06-18 1:50 ` Andy Lutomirski
2019-06-18 2:11 ` Kai Huang
2019-06-18 4:24 ` Andy Lutomirski
2019-06-18 14:19 ` Dave Hansen
2019-06-18 0:05 ` Kai Huang
2019-06-18 0:15 ` Andy Lutomirski
2019-06-18 1:35 ` Kai Huang
2019-06-18 1:43 ` Andy Lutomirski
2019-06-18 2:23 ` Kai Huang
2019-06-18 9:12 ` Peter Zijlstra
2019-06-18 14:09 ` Dave Hansen
2019-06-18 16:15 ` Kirill A. Shutemov
2019-06-18 16:22 ` Dave Hansen
2019-06-18 16:36 ` Andy Lutomirski
2019-06-18 16:48 ` Dave Hansen
2019-06-18 14:13 ` Dave Hansen
2019-06-17 23:59 ` Kai Huang
2019-06-18 1:34 ` Lendacky, Thomas
2019-06-18 1:40 ` Andy Lutomirski
2019-06-18 2:02 ` Lendacky, Thomas
2019-06-18 4:19 ` Andy Lutomirski
2019-05-08 14:44 ` [PATCH, RFC 46/62] x86/mm: Keep reference counts on encrypted VMAs " Kirill A. Shutemov
2019-06-14 11:54 ` Peter Zijlstra
2019-06-14 18:39 ` Alison Schofield
2019-05-08 14:44 ` [PATCH, RFC 47/62] mm: Restrict MKTME memory encryption to anonymous VMAs Kirill A. Shutemov
2019-06-14 11:55 ` Peter Zijlstra
2019-06-15 0:07 ` Alison Schofield
2019-05-08 14:44 ` [PATCH, RFC 48/62] selftests/x86/mktme: Test the MKTME APIs Kirill A. Shutemov
2019-05-08 17:09 ` Alison Schofield
2019-05-08 14:44 ` [PATCH, RFC 49/62] mm, x86: export several MKTME variables Kirill A. Shutemov
2019-06-14 11:56 ` Peter Zijlstra
2019-06-17 3:14 ` Kai Huang
2019-06-17 7:46 ` Peter Zijlstra
2019-06-17 8:39 ` Kai Huang
2019-06-17 11:25 ` Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 50/62] kvm, x86, mmu: setup MKTME keyID to spte for given PFN Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 51/62] iommu/vt-d: Support MKTME in DMA remapping Kirill A. Shutemov
2019-06-14 12:04 ` Peter Zijlstra
2019-05-08 14:44 ` [PATCH, RFC 52/62] x86/mm: introduce common code for mem encryption Kirill A. Shutemov
2019-05-08 16:58 ` Christoph Hellwig
2019-05-08 20:52 ` Jacob Pan
2019-05-08 21:21 ` Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 53/62] x86/mm: Use common code for DMA memory encryption Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 54/62] x86/mm: Disable MKTME on incompatible platform configurations Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 55/62] x86/mm: Disable MKTME if not all system memory supports encryption Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 56/62] x86: Introduce CONFIG_X86_INTEL_MKTME Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 57/62] x86/mktme: Overview of Multi-Key Total Memory Encryption Kirill A. Shutemov
2019-05-29 7:21 ` Mike Rapoport
2019-05-29 18:13 ` Alison Schofield
2019-07-14 18:16 ` Randy Dunlap
2019-07-15 9:02 ` Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 58/62] x86/mktme: Document the MKTME provided security mitigations Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 59/62] x86/mktme: Document the MKTME kernel configuration requirements Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 60/62] x86/mktme: Document the MKTME Key Service API Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 61/62] x86/mktme: Document the MKTME API for anonymous memory encryption Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 62/62] x86/mktme: Demonstration program using the MKTME APIs Kirill A. Shutemov
2019-05-29 7:30 ` Mike Rapoport [this message]
2019-05-29 18:20 ` [PATCH, RFC 00/62] Intel MKTME enabling Alison Schofield
2019-06-14 12:15 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190529073006.GG3656@rapoport-lnx \
--to=rppt@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=alison.schofield@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dhowells@redhat.com \
--cc=hpa@zytor.com \
--cc=jacob.jun.pan@linux.intel.com \
--cc=kai.huang@linux.intel.com \
--cc=keescook@chromium.org \
--cc=keyrings@vger.kernel.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@amacapital.net \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).