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...
