Re: [RFC 00/16] KVM protected memory extension

[Marc Zyngier]

Hi Sean,

On 2020-06-04 16:48, Sean Christopherson wrote:
> +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@xxxxxxxxxxxxx> 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?

KVM already handles the EL1->EL2->EL1 madness, meaning that from
an exception level perspective, the host kernel is already a guest.
It's just that this guest can directly change the hypervisor's text,
its page tables, and muck with about everything else.

De-privileging the memory access to non host EL1 memory is where the
ongoing effort is.

         M.
--
Jazz is not dead. It just smells funny...