Re: [PATCH v1 25/28] KVM: nSVM: Flush L2's ASID when emulating INVLPGA

On Fri, Jul 31, 2026 at 11:41=E2=80=AFPM Yosry Ahmed <[email protected]> wro=
te:
>
> > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> > index e4bda43238654..d7b20941b1fee 100644
> > --- a/arch/x86/kvm/svm/svm.c
> > +++ b/arch/x86/kvm/svm/svm.c
> > @@ -2425,17 +2425,51 @@ static int clgi_interception(struct kvm_vcpu *v=
cpu)
> >
> >  static int invlpga_interception(struct kvm_vcpu *vcpu)
> >  {
> > +       struct vcpu_svm *svm =3D to_svm(vcpu);
> >         /* FIXME: Handle an address size prefix. */
> >         gva_t gva =3D kvm_rax_read(vcpu);
> >         u32 asid =3D kvm_ecx_read(vcpu);
> > +       int cpu;
> >
> >         if (nested_svm_check_permissions(vcpu))
> >                 return 1;
> >
> >         trace_kvm_invlpga(to_svm(vcpu)->vmcb->save.rip, asid, gva);
> >
> > -       /* Let's treat INVLPGA the same as INVLPG (can be optimized!) *=
/
> > -       kvm_mmu_invlpg(vcpu, gva);
> > +       /*
> > +        * INVLPG on a non-canonical address is a NOP according to the =
SDM,
> > +        * assumethe same behavior from INVLPGA since the APM doesn't s=
pecify.
> > +        */
> > +       if (is_noncanonical_invlpg_address(gva, vcpu))
> > +               return kvm_skip_emulated_instruction(vcpu);
>
> From internal Sashiko:
> ---
> This is a pre-existing issue and was not introduced by the patch under re=
view,
> but if L1 is configured for 4-level paging and L2 is configured for 5-lev=
el
> paging, could this drop valid INVLPGA TLB flushes for L2?
>
> Since vcpu represents L1, the check is_noncanonical_invlpg_address(gva, v=
cpu)
> uses L1's canonical boundaries. If L1 executes INVLPGA to flush a valid 5=
7-bit
> virtual address for the L2 guest, will KVM incorrectly deem the L2 addres=
s as
> non-canonical and silently skip emulation?
>
> Bypassing both the hardware TLB flush and shadow page table synchronizati=
on
> could allow L2 to continue accessing memory through old translations,
> potentially leading to memory corruption or security boundary bypass
> inside L2.
> ---
>
> I need to take a closer look here, but if this is indeed an issue,
> even if pre-existing, it would only matter with this series. Before
> this series, even if INVLPGA is ignored we flush everything before
> running L2 anyway.

I don't think this is an issue. is_noncanonical_invlpg_address()
doesn't use "L1's canonical boundaries". It calls
is_noncanonical_address(.., X86EMUL_F_INVLPG), which calls
__is_canonical_address(.., max_host_virt_addr_bits()). So the
canonicality checks depend on the host support, not L1's CPUID or
configuration.

The only potentially interesting case is if hardware
only supports 48-bit addresses and L1 decides to emulate 57-bit
addresses (e.g. emulate 5-level paging on HW with only 4-level paging
support). In this case (if it all possible to begin with), I assume
it's L1's responsibility to make sure this is emulated correctly (e.g.
intercept L2's page faults with higher bits set).