On Fri, Sep 27, 2024, Paolo Bonzini wrote: > On Fri, Sep 27, 2024 at 2:18 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > > > Revert the entire KVM_X86_QUIRK_SLOT_ZAP_ALL series, as the code is buggy > > for shadow MMUs, and I'm not convinced a quirk is actually the right way > > forward. I'm not totally opposed to it (obviously, given that I suggested > > it at one point), but I would prefer to give ourselves ample time to sort > > out exactly how we want to move forward, i.e. not rush something in to > > unhose v6.12. > > Yeah, the code is buggy but I think it's safe enough to use code like the > one you wrote back in 2019; untested patch follows: ... > (Not too sure about using the sp_has_gptes() test, which is why I haven't > posted this yet). Heh, I was going to ask about that too. Luckily I read ahead :-) To be 100% safe, I think the zap needs to purge everything, even invalid SPs. I doubt it would ever cause problems to leave dangling invalid SPs, but I don't love the idea of avoiding UAF purely by relying on KVM not consuming stale info. The other thing that makes my head hurt is how SPs are tracked by direct SPs in the shadow MMU, i.e. by the effect of direct_map() and the guest hugepage case (it would be weird, but legal for the guest to create a hugepage that straddles a memslot boundary) rounding the gfn for the level when creating SPs. Hmm, but I suppose that's an argument against being paranoid for the !sp_has_gptes() case, as KVM already creates SPs with a target gfn that isn't covered by a memslot. Blech. > With respect to the choice of API, the quirk is at least good for > testing; this was already proven, I guess. True. I do think the documentation should be updated to be less prescriptive, i.e. to give KVM wiggle room. Disabling the quirk should only _allow_ KVM to a targeted/partial zap, it shouldn't _force_ KVM to do so. > Also I think it's safe to enable it for SEV/SEV-ES VM types: they > pretty much depend on NPT (see sev_hardware_setup), and with the > TDP MMU it should always be better to kill the PTEs for the memslot > (even if invalidating the whole MMU is cheap) to avoid having to > fault all the remainder of the memory back in. So I think the current > version of kvm_memslot_flush_zap_all() is better than using e.g. > kvm_arch_has_private_mem(). In practice, you're probably right. Realistically, the only memslot removal that would be problematic is the deletion of a large memslot, at which point SEV+ VMs are in for a world of hurt no matter what. > The only straggler is software-protected VMs, which I don't care > too much about; but if anything it's better to make them closer to > SNP and TDX VM types. > > For now I think I'll send the existing kvm/next to Linus and we > can sort it out next week, as the weekend (and the closure of the > merge window) is impending... Works for me. Thanks!
