From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> To: 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> Cc: 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, "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com> Subject: [PATCH, RFC 58/62] x86/mktme: Document the MKTME provided security mitigations Date: Wed, 8 May 2019 17:44:18 +0300 Message-ID: <20190508144422.13171-59-kirill.shutemov@linux.intel.com> (raw) In-Reply-To: <20190508144422.13171-1-kirill.shutemov@linux.intel.com> From: Alison Schofield <alison.schofield@intel.com> Describe the security benefits of Multi-Key Total Memory Encryption (MKTME) over Total Memory Encryption (TME) alone. 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 | 1 + Documentation/x86/mktme/mktme_mitigations.rst | 150 ++++++++++++++++++ 2 files changed, 151 insertions(+) create mode 100644 Documentation/x86/mktme/mktme_mitigations.rst diff --git a/Documentation/x86/mktme/index.rst b/Documentation/x86/mktme/index.rst index 1614b52dd3e9..a3a29577b013 100644 --- a/Documentation/x86/mktme/index.rst +++ b/Documentation/x86/mktme/index.rst @@ -6,3 +6,4 @@ Multi-Key Total Memory Encryption (MKTME) .. toctree:: mktme_overview + mktme_mitigations diff --git a/Documentation/x86/mktme/mktme_mitigations.rst b/Documentation/x86/mktme/mktme_mitigations.rst new file mode 100644 index 000000000000..90699c38750a --- /dev/null +++ b/Documentation/x86/mktme/mktme_mitigations.rst @@ -0,0 +1,150 @@ +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[1] 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[2]. + * 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. http://web.cs.ucdavis.edu/~rogaway/papers/offsets.pdf +2. This sustained time required for an attack could vary from days + to years depending on the attacker’s goals. -- 2.20.1
next prev parent reply index 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 ` Kirill A. Shutemov [this message] 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 ` [PATCH, RFC 00/62] Intel MKTME enabling Mike Rapoport 2019-05-29 18:20 ` 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=20190508144422.13171-59-kirill.shutemov@linux.intel.com \ --to=kirill.shutemov@linux.intel.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=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
Linux-mm Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-mm/0 linux-mm/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-mm linux-mm/ https://lore.kernel.org/linux-mm \ linux-mm@kvack.org public-inbox-index linux-mm Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kvack.linux-mm AGPL code for this site: git clone https://public-inbox.org/public-inbox.git