Re: [PATCH] x86/kfence: Avoid writing L1TF-vulnerable PTEs

[Andrew Morton <akpm@linux-foundation.org>]

On Tue,  6 Jan 2026 18:04:26 +0000 Andrew Cooper <andrew.cooper3@citrix.com> wrote:

> For native, the choice of PTE is fine.  There's real memory backing the
> non-present PTE.  However, for XenPV, Xen complains:
> 
>   (XEN) d1 L1TF-vulnerable L1e 8010000018200066 - Shadowing
> 
> To explain, some background on XenPV pagetables:
> 
>   Xen PV guests are control their own pagetables; they choose the new PTE
>   value, and use hypercalls to make changes so Xen can audit for safety.
> 
>   In addition to a regular reference count, Xen also maintains a type
>   reference count.  e.g. SegDesc (referenced by vGDT/vLDT),
>   Writable (referenced with _PAGE_RW) or L{1..4} (referenced by vCR3 or a
>   lower pagetable level).  This is in order to prevent e.g. a page being
>   inserted into the pagetables for which the guest has a writable mapping.
> 
>   For non-present mappings, all other bits become software accessible, and
>   typically contain metadata rather a real frame address.  There is nothing
>   that a reference count could sensibly be tied to.  As such, even if Xen
>   could recognise the address as currently safe, nothing would prevent that
>   frame from changing owner to another VM in the future.
> 
>   When Xen detects a PV guest writing a L1TF-PTE, it responds by activating
>   shadow paging. This is normally only used for the live phase of
>   migration, and comes with a reasonable overhead.
> 
> KFENCE only cares about getting #PF to catch wild accesses; it doesn't care
> about the value for non-present mappings.  Use a fully inverted PTE, to
> avoid hitting the slow path when running under Xen.
> 
> While adjusting the logic, take the opportunity to skip all actions if the
> PTE is already in the right state, half the number PVOps callouts, and skip
> TLB maintenance on a !P -> P transition which benefits non-Xen cases too.
> 
> Fixes: 1dc0da6e9ec0 ("x86, kfence: enable KFENCE for x86")

Seems that I sent 1dc0da6e9ec0 upstream so thanks, I'll grab this.  If
an x86 person chooses to handle it then I'll drop the mm.git version.

I'll add a cc:stable to the mm.git copy, just to be sure.

> Tested-by: Marco Elver <elver@google.com>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---

That "^---$" tells tooling "changelog stops here".

> CC: Alexander Potapenko <glider@google.com>
> CC: Marco Elver <elver@google.com>
> CC: Dmitry Vyukov <dvyukov@google.com>
> CC: Thomas Gleixner <tglx@linutronix.de>
> CC: Ingo Molnar <mingo@redhat.com>
> CC: Borislav Petkov <bp@alien8.de>
> CC: Dave Hansen <dave.hansen@linux.intel.com>
> CC: x86@kernel.org
> CC: "H. Peter Anvin" <hpa@zytor.com>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: Jann Horn <jannh@google.com>
> CC: kasan-dev@googlegroups.com
> CC: linux-kernel@vger.kernel.org
> 
> v1:
>  * First public posting.  This went to security@ first just in case, and
>    then I got districted with other things ahead of public posting.
> ---

That "^---$" would be better placed above the versioning info.

>
> ...
>