linux-kernel - Re: "KVM: x86/mmu: Overhaul TDP MMU zapping and flushing" breaks SVM on Hyper-V

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <35ff8f48-2677-78ea-b5f3-329c75ce65c9@redhat.com>
Date:   Mon, 13 Feb 2023 19:11:09 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Sean Christopherson <seanjc@...gle.com>,
        Jeremi Piotrowski <jpiotrowski@...ux.microsoft.com>
Cc:     kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Tianyu Lan <ltykernel@...il.com>,
        "Michael Kelley (LINUX)" <mikelley@...rosoft.com>
Subject: Re: "KVM: x86/mmu: Overhaul TDP MMU zapping and flushing" breaks SVM
 on Hyper-V

On 2/13/23 18:38, Sean Christopherson wrote:
> On Fri, Feb 10, 2023, Jeremi Piotrowski wrote:
>> Hi Paolo/Sean,
>>
>> We've noticed that changes introduced in "KVM: x86/mmu: Overhaul TDP MMU
>> zapping and flushing" conflict with a nested Hyper-V enlightenment that is
>> always enabled on AMD CPUs (HV_X64_NESTED_ENLIGHTENED_TLB). The scenario that
>> is affected is L0 Hyper-V + L1 KVM on AMD,
> 
> Do you see issues with Intel and HV_X64_NESTED_GUEST_MAPPING_FLUSH?  IIUC, on the
> KVM side, that setup is equivalent to HV_X64_NESTED_ENLIGHTENED_TLB.

My reading of the spec[1] is that HV_X64_NESTED_ENLIGHTENED_TLB will 
cause svm_flush_tlb_current to behave (in Intel parlance) as an INVVPID 
rather than an INVEPT.  So svm_flush_tlb_current has to be changed to 
also add a call to HvCallFlushGuestPhysicalAddressSpace.  I'm not sure 
if that's a good idea though.

First, that's a TLB shootdown rather than just a local thing; 
flush_tlb_current is supposed to be relatively cheap, and there would be 
a lot of them because of the unconditional calls to 
nested_svm_transition_tlb_flush on vmentry/vmexit.

Second, while the nCR3 matches across virtual processors for SVM, the 
(nCR3, ASID) pair does not, so it doesn't even make much sense to do a 
TLB shootdown.

Depending on the performance results of adding the hypercall to 
svm_flush_tlb_current, the fix could indeed be to just disable usage of 
HV_X64_NESTED_ENLIGHTENED_TLB.

Paolo

[1] 
https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/nested-virtualization