• Sean Christopherson's avatar
    KVM: x86: Force all MMUs to reinitialize if guest CPUID is modified · 49c6f875
    Sean Christopherson authored
    Invalidate all MMUs' roles after a CPUID update to force reinitizliation
    of the MMU context/helpers.  Despite the efforts of commit de3ccd26
    ("KVM: MMU: record maximum physical address width in kvm_mmu_extended_role"),
    there are still a handful of CPUID-based properties that affect MMU
    behavior but are not incorporated into mmu_role.  E.g. 1gb hugepage
    support, AMD vs. Intel handling of bit 8, and SEV's C-Bit location all
    factor into the guest's reserved PTE bits.
    
    The obvious alternative would be to add all such properties to mmu_role,
    but doing so provides no benefit over simply forcing a reinitialization
    on every CPUID update, as setting guest CPUID is a rare operation.
    
    Note, reinitializing all MMUs after a CPUID update does not fix all of
    KVM's woes.  Specifically, kvm_mmu_page_role doesn't track the CPUID
    properties, which means that a vCPU can reuse shadow pages that should
    not exist for the new vCPU model, e.g. that map GPAs that are now illegal
    (due to MAXPHYADDR changes) or that set bits that are now reserved
    (PAGE_SIZE for 1gb pages), etc...
    
    Tracking the relevant CPUID properties in kvm_mmu_page_role would address
    the majority of problems, but fully tracking that much state in the
    shadow page role comes with an unpalatable cost as it would require a
    non-trivial increase in KVM's memory footprint.  The GBPAGES case is even
    worse, as neither Intel nor AMD provides a way to disable 1gb hugepage
    support in the hardware page walker, i.e. it's a virtualization hole that
    can't be closed when using TDP.
    
    In other words, resetting the MMU after a CPUID update is largely a
    superficial fix.  But, it will allow reverting the tracking of MAXPHYADDR
    in the mmu_role, and that case in particular needs to mostly work because
    KVM's shadow_root_level depends on guest MAXPHYADDR when 5-level paging
    is supported.  For cases where KVM botches guest behavior, the damage is
    limited to that guest.  But for the shadow_root_level, a misconfigured
    MMU can cause KVM to incorrectly access memory, e.g. due to walking off
    the end of its shadow page tables.
    
    Fixes: 7dcd5755 ("x86/kvm/mmu: check if tdp/shadow MMU reconfiguration is needed")
    Cc: Yu Zhang <yu.c.zhang@linux.intel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: default avatarSean Christopherson <seanjc@google.com>
    Message-Id: <20210622175739.3610207-7-seanjc@google.com>
    Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
    49c6f875
cpuid.c 33.3 KB