Message-ID: <D45D9NN03CSH.3B25KJ1XKV6XE@amazon.com>
Date: Fri, 13 Sep 2024 18:26:54 +0000
From: Nicolas Saenz Julienne <nsaenz@...zon.com>
To: Sean Christopherson <seanjc@...gle.com>
CC: <linux-kernel@...r.kernel.org>, <kvm@...r.kernel.org>,
	<pbonzini@...hat.com>, <vkuznets@...hat.com>, <linux-doc@...r.kernel.org>,
	<linux-hyperv@...r.kernel.org>, <linux-arch@...r.kernel.org>,
	<linux-trace-kernel@...r.kernel.org>, <graf@...zon.de>,
	<dwmw2@...radead.org>, <pdurrant@...zon.com>, <mlevitsk@...hat.com>,
	<jgowans@...zon.com>, <corbet@....net>, <decui@...rosoft.com>,
	<tglx@...utronix.de>, <mingo@...hat.com>, <bp@...en8.de>,
	<dave.hansen@...ux.intel.com>, <x86@...nel.org>, <amoorthy@...gle.com>
Subject: Re: [PATCH 16/18] KVM: x86: Take mem attributes into account when faulting
 memory

On Thu Aug 22, 2024 at 4:58 PM UTC, Sean Christopherson wrote:
> On Thu, Aug 22, 2024, Nicolas Saenz Julienne wrote:
> > On Sun Jun 9, 2024 at 3:49 PM UTC, Nicolas Saenz Julienne wrote:
> > > Take into account access restrictions memory attributes when faulting
> > > guest memory. Prohibited memory accesses will cause an user-space fault
> > > exit.
> > >
> > > Additionally, bypass a warning in the !tdp case. Access restrictions in
> > > guest page tables might not necessarily match the host pte's when memory
> > > attributes are in use.
> > >
> > > Signed-off-by: Nicolas Saenz Julienne <nsaenz@...zon.com>
> >
> > I now realize that only taking into account memory attributes during
> > faults isn't good enough for VSM. We should check the attributes anytime
> > KVM takes GPAs as input for any action initiated by the guest. If the
> > memory attributes are incompatible with such action, it should be
> > stopped. Failure to do so opens side channels that unprivileged VTLs can
> > abuse to infer information about privileged VTL. Some examples I came up
> > with:
> > - Guest page walks: VTL0 could install malicious directory entries that
> >   point to GPAs only visible to VTL1. KVM will happily continue the
> >   walk. Among other things, this could be use to infer VTL1's GVA->GPA
> >   mappings.
> > - PV interfaces like the Hyper-V TSC page or VP assist page, could be
> >   used to modify portions of VTL1 memory.
> > - Hyper-V hypercalls that take GPAs as input/output can be abused in a
> >   myriad of ways. Including ones that exit into user-space.
> >
> > We would be protected against all these if we implemented the memory
> > access restrictions through the memory slots API. As is, it has the
> > drawback of having to quiesce the whole VM for any non-trivial slot
> > modification (i.e. VSM's memory protections). But if we found a way to
> > speed up the slot updates we could rely on that, and avoid having to
> > teach kvm_read/write_guest() and friends to deal with memattrs. Note
> > that we would still need to use memory attributes to request for faults
> > to exit onto user-space on those select GPAs. Any opinions or
> > suggestions?
> >
> > Note that, for now, I'll stick with the memory attributes approach to
> > see what the full solution looks like.
>
> FWIW, I suspect we'll be better off honoring memory attributes.  It's not just
> the KVM side that has issues with memslot updates, my understanding is userspace
> has also built up "slow" code with respect to memslot updates, in part because
> it's such a slow path in KVM.

Sean, since I see you're looking at the series. I don't think it's worth
spending too much time with the memory attributes patches. Since
figuring out the sidechannels mentioned above, I found even more
shortcomings in this implementation. I'm reworking the whole thing in a
separate series [1], taking into account sidechannels, MMIO, non-TDP
MMUs, etc. and introducing selftests and an in-depth design document.

[1] https://github.com/vianpl/linux branch 'vsm/memory-protections' (wip)

Thanks,
Nicolas

Powered by blists - more mailing lists