[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cd292393f8e45407b2754efbaf89aa70@kernel.org>
Date: Thu, 04 Jun 2020 17:27:34 +0100
From: Marc Zyngier <maz@...nel.org>
To: Sean Christopherson <sean.j.christopherson@...el.com>
Cc: "Kirill A. Shutemov" <kirill@...temov.name>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>,
David Rientjes <rientjes@...gle.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Kees Cook <keescook@...omium.org>,
Will Drewry <wad@...omium.org>,
"Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
"Kleen, Andi" <andi.kleen@...el.com>, x86@...nel.org,
kvm@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
kernel-team@...roid.com, will@...nel.org,
Jun Nakajima <jun.nakajima@...el.com>
Subject: Re: [RFC 00/16] KVM protected memory extension
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@...temov.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?
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...
Powered by blists - more mailing lists