From: Andy Lutomirski <firstname.lastname@example.org> To: Dave Hansen <email@example.com> Cc: Andrew Lutomirski <firstname.lastname@example.org>, Alison Schofield <email@example.com>, Matthew Wilcox <firstname.lastname@example.org>, Dan Williams <email@example.com>, David Howells <firstname.lastname@example.org>, Thomas Gleixner <email@example.com>, James Morris <firstname.lastname@example.org>, Ingo Molnar <email@example.com>, "H. Peter Anvin" <firstname.lastname@example.org>, Borislav Petkov <email@example.com>, Peter Zijlstra <firstname.lastname@example.org>, "Kirill A. Shutemov" <email@example.com>, firstname.lastname@example.org, Jun Nakajima <email@example.com>, "Sakkinen, Jarkko" <firstname.lastname@example.org>, email@example.com, LSM List <firstname.lastname@example.org>, Linux-MM <email@example.com>, X86 ML <firstname.lastname@example.org> Subject: Re: [RFC v2 00/13] Multi-Key Total Memory Encryption API (MKTME) Date: Thu, 6 Dec 2018 11:10:43 -0800 Message-ID: <CALCETrVPhay-ziRVjL9dDCwJQHhr4HfG5aGJzYh06k6HEMZTiQ@mail.gmail.com> (raw) In-Reply-To: <email@example.com> > On Dec 6, 2018, at 7:39 AM, Dave Hansen <firstname.lastname@example.org> wrote: >>>> the direct map as well, probably using the pageattr.c code. >>> >>> The current, public hardware spec has a description of what's required >>> to maintain cache coherency. Basically, you can keep as many mappings >>> of a physical page as you want, but only write to one mapping at a time, >>> and clflush the old one when you want to write to a new one. >> >> Surely you at least have to clflush the old mapping and then the new >> mapping, since the new mapping could have been speculatively read. > > Nope. The coherency is "fine" unless you have writeback of an older > cacheline that blows away newer data. CPUs that support MKTME are > guaranteed to never do writeback of the lines that could be established > speculatively or from prefetching. How is that sufficient? Suppose I have some physical page mapped with keys 1 and 2. #1 is logically live and I write to it. Then I prefetch or otherwise populate mapping 2 into the cache (in the S state, presumably). Now I clflush mapping 1 and read 2. It contains garbage in the cache, but the garbage in the cache is inconsistent with the garbage in memory. This can’t be a good thing, even if no writeback occurs. I suppose the right fix is to clflush the old mapping and then to zero the new mapping. > >>>> Finally, If you're going to teach the kernel how to have some user >>>> pages that aren't in the direct map, you've essentially done XPO, >>>> which is nifty but expensive. And I think that doing this gets you >>>> essentially all the benefit of MKTME for the non-pmem use case. Why >>>> exactly would any software want to use anything other than a >>>> CPU-managed key for anything other than pmem? >>> >>> It is handy, for one, to let you "cluster" key usage. If you have 5 >>> Pepsi VMs and 5 Coke VMs, each Pepsi one using the same key and each >>> Coke one using the same key, you can boil it down to only 2 hardware >>> keyid slots that get used, and do this transparently. >> >> I understand this from a marketing perspective but not a security >> perspective. Say I'm Coke and you've sold me some VMs that are >> "encrypted with a Coke-specific key and no other VMs get to use that >> key." I can't think of *any* not-exceedingly-contrived attack in >> which this makes the slightest difference. If Pepsi tries to attack >> Coke without MKTME, then they'll either need to get the hypervisor to >> leak Coke's data through the direct map or they'll have to find some >> way to corrupt a page table or use something like L1TF to read from a >> physical address Coke owns. With MKTME, if they can read through the >> host direct map, then they'll get Coke's cleartext, and if they can >> corrupt a page table or use L1TF to read from your memory, they'll get >> Coke's cleartext. > > The design definitely has the hypervisor in the trust boundary. If the > hypervisor is evil, or if someone evil compromises the hypervisor, MKTME > obviously provides less protection. > > I guess the question ends up being if this makes its protections weak > enough that we should not bother merging it in its current form. Indeed, but I’d ask another question too: I expect that MKTME is weak enough that it will be improved, and without seeing the improvement, it seems quite plausible that using the improvement will require radically reworking the kernel implementation. As a straw man, suppose we get a way to say “this key may only be accessed through such-and-such VPID or by using a special new restricted facility for the hypervisor to request access”. Now we have some degree of serious protection, but it doesn’t work, by design, for anonymous memory. Similarly, something that looks more like AMD's SEV would be very very awkward to support with anything like the current API proposal. > > I still have the homework assignment to go figure out why folks want the > protections as they stand.
next prev parent reply index Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-12-04 7:39 Alison Schofield 2018-12-04 7:39 ` [RFC v2 01/13] x86/mktme: Document the MKTME APIs Alison Schofield 2018-12-05 18:11 ` Andy Lutomirski 2018-12-05 19:22 ` Alison Schofield 2018-12-05 23:35 ` Andy Lutomirski 2018-12-06 8:04 ` Sakkinen, Jarkko 2018-12-04 7:39 ` [RFC v2 02/13] mm: Generalize the mprotect implementation to support extensions Alison Schofield 2018-12-06 8:08 ` Sakkinen, Jarkko 2018-12-04 7:39 ` [RFC v2 03/13] syscall/x86: Wire up a new system call for memory encryption keys Alison Schofield 2018-12-04 7:39 ` [RFC v2 04/13] x86/mm: Add helper functions for MKTME " Alison Schofield 2018-12-04 9:14 ` Peter Zijlstra 2018-12-05 5:49 ` Alison Schofield 2018-12-04 15:35 ` Andy Lutomirski 2018-12-05 5:52 ` Alison Schofield 2018-12-06 8:31 ` Sakkinen, Jarkko 2018-12-04 7:39 ` [RFC v2 05/13] x86/mm: Set KeyIDs in encrypted VMAs Alison Schofield 2018-12-06 8:37 ` Sakkinen, Jarkko 2018-12-04 7:39 ` [RFC v2 06/13] mm: Add the encrypt_mprotect() system call Alison Schofield 2018-12-06 8:38 ` Sakkinen, Jarkko 2018-12-04 7:39 ` [RFC v2 07/13] x86/mm: Add helpers for reference counting encrypted VMAs Alison Schofield 2018-12-04 8:58 ` Peter Zijlstra 2018-12-05 5:28 ` Alison Schofield 2018-12-04 7:39 ` [RFC v2 08/13] mm: Use reference counting for " Alison Schofield 2018-12-04 7:39 ` [RFC v2 09/13] mm: Restrict memory encryption to anonymous VMA's Alison Schofield 2018-12-04 9:10 ` Peter Zijlstra 2018-12-05 5:30 ` Alison Schofield 2018-12-05 9:07 ` Peter Zijlstra 2018-12-04 7:39 ` [RFC v2 10/13] keys/mktme: Add the MKTME Key Service type for memory encryption Alison Schofield 2018-12-06 8:51 ` Sakkinen, Jarkko 2018-12-06 8:54 ` Sakkinen, Jarkko 2018-12-06 15:11 ` Dave Hansen 2018-12-06 22:56 ` Sakkinen, Jarkko 2018-12-04 7:39 ` [RFC v2 11/13] keys/mktme: Program memory encryption keys on a system wide basis Alison Schofield 2018-12-04 9:21 ` Peter Zijlstra 2018-12-04 9:50 ` Kirill A. Shutemov 2018-12-05 5:44 ` Alison Schofield 2018-12-05 5:43 ` Alison Schofield 2018-12-05 9:10 ` Peter Zijlstra 2018-12-05 17:26 ` Alison Schofield 2018-12-04 7:39 ` [RFC v2 12/13] keys/mktme: Save MKTME data if kernel cmdline parameter allows Alison Schofield 2018-12-04 9:22 ` Peter Zijlstra 2018-12-07 2:14 ` Huang, Kai 2018-12-07 3:42 ` Alison Schofield 2018-12-07 6:39 ` Jarkko Sakkinen 2018-12-07 6:45 ` Jarkko Sakkinen 2018-12-07 11:47 ` Kirill A. Shutemov 2018-12-04 7:40 ` [RFC v2 13/13] keys/mktme: Support CPU Hotplug for MKTME keys Alison Schofield 2018-12-04 9:28 ` Peter Zijlstra 2018-12-05 5:32 ` Alison Schofield 2018-12-04 9:31 ` Peter Zijlstra 2018-12-05 5:36 ` Alison Schofield 2018-12-04 9:25 ` [RFC v2 00/13] Multi-Key Total Memory Encryption API (MKTME) Peter Zijlstra 2018-12-04 9:46 ` Kirill A. Shutemov 2018-12-05 20:32 ` Sakkinen, Jarkko 2018-12-06 11:22 ` Kirill A. Shutemov 2018-12-06 14:59 ` Dave Hansen 2018-12-07 10:12 ` Huang, Kai 2018-12-06 21:23 ` Sakkinen, Jarkko 2018-12-07 11:54 ` Kirill A. Shutemov 2018-12-04 19:19 ` Andy Lutomirski 2018-12-04 20:00 ` Andy Lutomirski 2018-12-04 20:32 ` Dave Hansen 2018-12-05 22:19 ` Sakkinen, Jarkko 2018-12-07 2:05 ` Huang, Kai 2018-12-07 6:48 ` Jarkko Sakkinen 2018-12-07 11:57 ` Kirill A. Shutemov 2018-12-07 21:59 ` Sakkinen, Jarkko 2018-12-07 23:45 ` Sakkinen, Jarkko 2018-12-07 23:48 ` Andy Lutomirski 2018-12-08 1:33 ` Huang, Kai 2018-12-08 3:53 ` Sakkinen, Jarkko 2018-12-12 15:31 ` Sakkinen, Jarkko 2018-12-12 16:29 ` Andy Lutomirski 2018-12-12 16:43 ` Sakkinen, Jarkko 2018-12-12 23:27 ` Huang, Kai 2018-12-13 5:49 ` Sakkinen, Jarkko 2018-12-13 5:52 ` Sakkinen, Jarkko 2018-12-12 23:24 ` Huang, Kai 2018-12-07 23:35 ` Eric Rannaud 2018-12-05 23:49 ` Dave Hansen 2018-12-06 1:09 ` Andy Lutomirski 2018-12-06 1:25 ` Dan Williams 2018-12-06 15:39 ` Dave Hansen 2018-12-06 19:10 ` Andy Lutomirski [this message] 2018-12-06 19:31 ` Dave Hansen 2018-12-07 1:55 ` Huang, Kai 2018-12-07 4:23 ` Dave Hansen 2018-12-07 23:53 ` Andy Lutomirski 2018-12-08 1:11 ` Dave Hansen 2018-12-08 2:07 ` Huang, Kai 2018-12-05 20:30 ` Sakkinen, Jarkko
Reply instructions: You may reply publically 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=CALCETrVPhay-ziRVjL9dDCwJQHhr4HfG5aGJzYh06k6HEMZTiQ@mail.gmail.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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-Security-Module Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-security-module/0 linux-security-module/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-security-module linux-security-module/ https://lore.kernel.org/linux-security-module \ email@example.com firstname.lastname@example.org public-inbox-index linux-security-module Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-security-module AGPL code for this site: git clone https://public-inbox.org/ public-inbox