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@xxxxxxxxxx> > > > > 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
