Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: 9atNL4XUTZ19L5gP8tQAWfViLRx27VV39bZUzYFE2wr//jNLRr0MMbrx091SntBXHG2XNJ0+LA
 adakuz7Lj1Eg==
IronPort-SDR: czgfksgqsVm/VnDrBXeRHwEEa5jbQTP7gldiJ1egYZulRkXR9PaUheprFn3q2xd5lhLpAlflog
 lDqkO3C6d/Jw==
Date:   Thu, 4 Jun 2020 08:48:35 -0700
From:   Sean Christopherson <sean.j.christopherson@intel.com>
To:     Marc Zyngier <maz@kernel.org>
Cc:     "Kirill A. Shutemov" <kirill@shutemov.name>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Andy Lutomirski <luto@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Jim Mattson <jmattson@google.com>,
        Joerg Roedel <joro@8bytes.org>,
        David Rientjes <rientjes@google.com>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Kees Cook <keescook@chromium.org>,
        Will Drewry <wad@chromium.org>,
        "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
        "Kleen, Andi" <andi.kleen@intel.com>, x86@kernel.org,
        kvm@vger.kernel.org, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        kernel-team@android.com, will@kernel.org,
        Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [RFC 00/16] KVM protected memory extension
Message-ID: <20200604154835.GE30223@linux.intel.com>
References: <20200522125214.31348-1-kirill.shutemov@linux.intel.com>
 <20200604161523.39962919@why>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200604161523.39962919@why>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

+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" <kirill@shutemov.name> 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.