Re: [PATCH] KVM: nVMX: Don't flush shadow VMCS12 to guest memory during vCPU teardown

[Sean Christopherson <seanjc@google.com>]

On Thu, Sep 10, 2026, Sean Christopherson wrote:
> On Thu, Sep 10, 2026, James Houghton wrote:
> > On Wed, Sep 9, 2026 at 12:00 PM Sean Christopherson <seanjc@google.com> wrote:
> > > If the above works for PPC, then KVM can nuke memslots before calling into
> > > kvm_arch_destroy_vm().  x86's asinine memslot deletion in kvm_arch_destroy_vm()
> > > needs to be addressed, but that code exists purely to do vm_munmap(), and can
> > > and should be moved to kvm_arch_free_memslot().
> > >
> > > All that said, I'm not sure this aggressive fix is the right thing to send to
> > > stable@.  For that, James' suggestion of hardening KVM's usage of
> > > __copy_{to,from}_user() seems like the best blend of being comprehensive without
> > > being overly invasive/risky.
> > 
> > This seems kind of nightmareish to backport; there are a lot of
> > copy_*_user() callsites that will need updating. Maybe I have a
> > different idea of the diff you're suggesting.
> 
> Nah, it's not many, because it's only the __copy_{to,from}_user{,inatomic}() usage
> that needs handling.  Everything else is strictly scoped to an ioctl, where (a)
> current->mm can't be NULL and (b) KVM doesn't make any assumption about the address
> space.
> 
> At a glance, it's 11 total: 5 in virt/kvm, 4 in vmx.c, and 2 in PPC's book3s_64_mmu_radix.c.
> Well, plus 4 more to also harden {,__}kvm_{get,put}_guest().
> 
> And even if that number were doubled or tripled, the backports would still be
> relatively easy.  The overwhelming majority won't conflict, and the few that do
> should be trivial to resolve (more than likely, simply drop the change).

To clarify: my goal isn't to harden literally every uaccess in KVM, just those
that have a dependency on memslots, i.e. are accessing guest memory.  Those also
happen to be the ones that are often buried deep in KVM, in widely-used APIs.