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

[Nakajima, Jun]

> 
> On Jun 4, 2020, at 9:35 AM, Will Deacon <will@xxxxxxxxxx> wrote:
> 
> Hi Sean,
> 
> On Thu, Jun 04, 2020 at 08:48:35AM -0700, Sean Christopherson wrote:
>> On Thu, Jun 04, 2020 at 04:15:23PM +0100, Marc Zyngier wrote:
>>> 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/
>> 

We (Intel virtualization team) are also working on a similar thing, prototyping to meet such requirements, i..e "some level of confidentiality to guestsâ. Linux/KVM is the host, and the Kirillâs patches are helpful when removing the mappings from the host to achieve memory isolation of a guest. But, itâs not easy to prove there are no other mappings.

To raise the level of security, our idea is to de-privilege the host kernel just to enforce memory isolation using EPT (Extended Page Table) that virtualizes guest (the host kernel in this case) physical memory; almost everything is passthrough. And the EPT for the host kernel excludes the memory for the guest(s) that has confidential info. So, the host kernel shouldnât cause VM exits as long as itâs behaving well (CPUID still causes a VM exit, though). 

When the control enters KVM, we go back to privileged (hypervisor or root) mode, and it works as does today. Once a VM exit happens, we will stay in the root mode as long as the exit can be handled within KVM. If we need to depend on the host kernel, we de-privilege the host kernel (i.e. VM enter). Yes, it sounds ugly.

There are cleaner (but more expensive) approaches, and we are collecting data at this point. For example, we could run the host kernel (like Xen dom0) on top of a thin? hypervisor that consists of KVM and minimally configured Linux.  

> 
>> 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?
> 
> Yes, and this is actually the way that KVM works on some Arm CPUs today,
> as the original virtualisation extensions in the Armv8 architecture do
> not make it possible to run the kernel directly at EL2 (for example, there
> is only one page-table base register). This was later addressed in the
> architecture by the "Virtualisation Host Extensions (VHE)", and so KVM
> supports both options.
> 
> With non-VHE today, there is a small amount of "world switch" code at
> EL2 which is installed by the host kernel and provides a way to transition
> between the host and the guest. If the host needs to do something at EL2
> (e.g. privileged TLB invalidation), then it makes a hypercall (HVC instruction)
> via the kvm_call_hyp() macro (and this ends up just being a function call
> for VHE).
> 
>> 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?
> 
> The logic is there as part of the non-VHE support code, but it's not great
> from a security angle. For example, the guest stage-2 page-tables are still
> allocated by the host, the host has complete access to guest and hypervisor
> memory (including hypervisor text) and things like kvm_call_hyp() are a bit
> of an open door. We're working on making the EL2 code more self contained,
> so that after the host has initialised KVM, it can shut the door and the
> hypervisor can install a stage-2 translation over the host, which limits its
> access to hypervisor and guest memory. There will clearly be IOMMU work as
> well to prevent DMA attacks.

Sounds interesting. 

--- 
Jun
Intel Open Source Technology Center