From: Sean Christopherson <email@example.com> To: Marc Zyngier <firstname.lastname@example.org> Cc: "Kirill A. Shutemov" <email@example.com>, Dave Hansen <firstname.lastname@example.org>, Andy Lutomirski <email@example.com>, Peter Zijlstra <firstname.lastname@example.org>, Paolo Bonzini <email@example.com>, Vitaly Kuznetsov <firstname.lastname@example.org>, Wanpeng Li <email@example.com>, Jim Mattson <firstname.lastname@example.org>, Joerg Roedel <email@example.com>, David Rientjes <firstname.lastname@example.org>, Andrea Arcangeli <email@example.com>, Kees Cook <firstname.lastname@example.org>, Will Drewry <email@example.com>, "Edgecombe, Rick P" <firstname.lastname@example.org>, "Kleen, Andi" <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, "Kirill A. Shutemov" <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, Jun Nakajima <email@example.com> Subject: Re: [RFC 00/16] KVM protected memory extension Date: Thu, 4 Jun 2020 08:48:35 -0700 Message-ID: <20200604154835.GE30223@linux.intel.com> (raw) In-Reply-To: <20200604161523.39962919@why> +Jun On Thu, Jun 04, 2020 at 04:15:23PM +0100, Marc Zyngier wrote: > Hi Kirill, > > Thanks for this. > > On Fri, 22 May 2020 15:51:58 +0300 > "Kirill A. Shutemov" <firstname.lastname@example.org> wrote: > > > == Background / Problem == > > > > There are a number of hardware features (MKTME, SEV) which protect guest > > memory from some unauthorized host access. The patchset proposes a purely > > software feature that mitigates some of the same host-side read-only > > attacks. > > > > > > == What does this set mitigate? == > > > > - Host kernel ”accidental” access to guest data (think speculation) > > > > - Host kernel induced access to guest data (write(fd, &guest_data_ptr, len)) > > > > - Host userspace access to guest data (compromised qemu) > > > > == What does this set NOT mitigate? == > > > > - Full host kernel compromise. Kernel will just map the pages again. > > > > - Hardware attacks > > Just as a heads up, we (the Android kernel team) are currently > involved in something pretty similar for KVM/arm64 in order to bring > some level of confidentiality to guests. > > The main idea is to de-privilege the host kernel by wrapping it in its > own nested set of page tables which allows us to remove memory > allocated to guests on a per-page basis. The core hypervisor runs more > or less independently at its own privilege level. It still is KVM > though, as we don't intend to reinvent the wheel. > > Will has written a much more lingo-heavy description here: > https://lore.kernel.org/kvmarm/20200327165935.GA8048@willie-the-truck/ Pardon my arm64 ignorance... IIUC, in this mode, the host kernel runs at EL1? And to switch to a guest it has to bounce through EL2, which is KVM, or at least a chunk of KVM? I assume the EL1->EL2->EL1 switch is done by trapping an exception of some form? If all of the above are "yes", does KVM already have the necessary logic to perform the EL1->EL2->EL1 switches, or is that being added as part of the de-privileging effort? > This works for one of the virtualization modes that arm64 can use (what > we call non-VHE, or nVHE for short). The other mode (VHE), is much more > similar to what happens on other architectures, where the kernel and > the hypervisor are one single entity. In this case, we cannot use the > same trick with nested page tables, and have to rely on something that > would very much look like what you're proposing. > > Note that the two modes of the architecture would benefit from this > work anyway, as I'd like the host to know that we've pulled memory > from under its feet. Since you have done most of the initial work, I > intend to give it a go on arm64 shortly and see what sticks.
next prev parent reply index Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-05-22 12:51 Kirill A. Shutemov 2020-05-22 12:51 ` [RFC 01/16] x86/mm: Move force_dma_unencrypted() to common code Kirill A. Shutemov 2020-05-22 12:52 ` [RFC 02/16] x86/kvm: Introduce KVM memory protection feature Kirill A. Shutemov 2020-05-25 14:58 ` Vitaly Kuznetsov 2020-05-25 15:15 ` Kirill A. Shutemov 2020-05-27 5:03 ` Sean Christopherson 2020-05-27 8:39 ` Vitaly Kuznetsov 2020-05-27 8:52 ` Sean Christopherson 2020-06-03 2:09 ` Huang, Kai 2020-06-03 11:14 ` Vitaly Kuznetsov 2020-05-22 12:52 ` [RFC 03/16] x86/kvm: Make DMA pages shared Kirill A. Shutemov 2020-05-22 12:52 ` [RFC 04/16] x86/kvm: Use bounce buffers for KVM memory protection Kirill A. Shutemov 2020-05-22 12:52 ` [RFC 05/16] x86/kvm: Make VirtIO use DMA API in KVM guest Kirill A. Shutemov 2020-05-22 12:52 ` [RFC 06/16] KVM: Use GUP instead of copy_from/to_user() to access guest memory Kirill A. Shutemov 2020-05-25 15:08 ` Vitaly Kuznetsov 2020-05-25 15:17 ` Kirill A. Shutemov 2020-06-01 16:35 ` Paolo Bonzini 2020-06-02 13:33 ` Kirill A. Shutemov 2020-05-26 6:14 ` Mike Rapoport 2020-05-26 21:56 ` Kirill A. Shutemov 2020-05-29 15:24 ` Kees Cook 2020-05-22 12:52 ` [RFC 07/16] KVM: mm: Introduce VM_KVM_PROTECTED Kirill A. Shutemov 2020-05-26 6:15 ` Mike Rapoport 2020-05-26 22:01 ` Kirill A. Shutemov 2020-05-26 6:40 ` John Hubbard 2020-05-26 22:04 ` Kirill A. Shutemov 2020-05-22 12:52 ` [RFC 08/16] KVM: x86: Use GUP for page walk instead of __get_user() Kirill A. Shutemov 2020-05-22 12:52 ` [RFC 09/16] KVM: Protected memory extension Kirill A. Shutemov 2020-05-25 15:26 ` Vitaly Kuznetsov 2020-05-25 15:34 ` Kirill A. Shutemov 2020-06-03 1:34 ` Huang, Kai 2020-05-22 12:52 ` [RFC 10/16] KVM: x86: Enabled protected " Kirill A. Shutemov 2020-05-25 15:26 ` Vitaly Kuznetsov 2020-05-26 6:16 ` Mike Rapoport 2020-05-26 21:58 ` Kirill A. Shutemov 2020-05-22 12:52 ` [RFC 11/16] KVM: Rework copy_to/from_guest() to avoid direct mapping Kirill A. Shutemov 2020-05-22 12:52 ` [RFC 12/16] x86/kvm: Share steal time page with host Kirill A. Shutemov 2020-05-22 12:52 ` [RFC 13/16] x86/kvmclock: Share hvclock memory with the host Kirill A. Shutemov 2020-05-25 15:22 ` Vitaly Kuznetsov 2020-05-25 15:25 ` Kirill A. Shutemov 2020-05-25 15:42 ` Vitaly Kuznetsov 2020-05-22 12:52 ` [RFC 14/16] KVM: Introduce gfn_to_pfn_memslot_protected() Kirill A. Shutemov 2020-05-22 12:52 ` [RFC 15/16] KVM: Handle protected memory in __kvm_map_gfn()/__kvm_unmap_gfn() Kirill A. Shutemov 2020-05-22 12:52 ` [RFC 16/16] KVM: Unmap protected pages from direct mapping Kirill A. Shutemov 2020-05-26 6:16 ` Mike Rapoport 2020-05-26 22:10 ` Kirill A. Shutemov 2020-05-25 5:27 ` [RFC 00/16] KVM protected memory extension Kirill A. Shutemov 2020-05-25 13:47 ` Liran Alon 2020-05-25 14:46 ` Kirill A. Shutemov 2020-05-25 15:56 ` Liran Alon 2020-05-26 6:17 ` Mike Rapoport 2020-05-26 10:16 ` Liran Alon 2020-05-26 11:38 ` Mike Rapoport 2020-05-27 15:45 ` Dave Hansen 2020-05-27 21:22 ` Mike Rapoport 2020-06-04 15:15 ` Marc Zyngier 2020-06-04 15:48 ` Sean Christopherson [this message] 2020-06-04 16:27 ` Marc Zyngier 2020-06-04 16:35 ` Will Deacon 2020-06-04 19:09 ` Nakajima, Jun 2020-06-04 21:03 ` Jim Mattson 2020-06-04 23:29 ` Nakajima, Jun
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=20200604154835.GE30223@linux.intel.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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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
KVM Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/kvm/0 kvm/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 kvm kvm/ https://lore.kernel.org/kvm \ firstname.lastname@example.org public-inbox-index kvm Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.kvm AGPL code for this site: git clone https://public-inbox.org/public-inbox.git