Fix a contrived bug where KVM can create a shadow-present SPTE with RWX=0
if L1 modifies an existing RX or RWX 4kb SPTE to be X-only and the combined
permissions for the upper level SPTEs yield !X.

Patch 2 adds a comment explaining why FNAME(sync_page) isn't repsonsible
for flushing synchronized entries that reduce protections, e.g. drop X
(or add NX).  Lack of a flush made me do a double-take and a lot of
staring.

Sean Christopherson (2):
  KVM: x86/mmu: Drop RWX=0 SPTEs during ept_sync_page()
  KVM: x86/mmu: Comment FNAME(sync_page) to document TLB flushing logic

 arch/x86/kvm/mmu/paging_tmpl.h | 18 +++++++++++++++++-
 arch/x86/kvm/mmu/spte.c        |  2 ++
 2 files changed, 19 insertions(+), 1 deletion(-)


base-commit: 2764011106d0436cb44702cfb0981339d68c3509
-- 
2.36.0.550.gb090851708-goog

Queued, thanks.  Here is the new message for patch 1:

    All of sync_page()'s existing checks filter out only !PRESENT gPTE,
    because without execute-only, all upper levels are guaranteed to be at
    least READABLE.  However, if EPT with execute-only support is in use by
    L1, KVM can create an SPTE that is shadow-present but guest-inaccessible
    (RWX=0) if the upper level combined permissions are R (or RW) and
    the leaf EPTE is changed from R (or RW) to X.  Because the EPTE is
    considered present when viewed in isolation, and no reserved bits are set,
    FNAME(prefetch_invalid_gpte) will consider the GPTE valid, and cause a
    not-present SPTE to be created.

    The SPTE is "correct": the guest translation is inaccessible because
    the combined protections of all levels yield RWX=0, and KVM will just
    redirect any vmexits to the guest.  If EPT A/D bits are disabled, KVM
    can mistake the SPTE for an access-tracked SPTE, but again such confusion
    isn't fatal, as the "saved" protections are also RWX=0.  However,
    creating a useless SPTE in general means that KVM messed up something,
    even if this particular goof didn't manifest as a functional bug.
    So, drop SPTEs whose new protections will yield a RWX=0 SPTE, and
    add a WARN in make_spte() to detect creation of SPTEs that will
    result in RWX=0 protections.

Paolo