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

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: <CAG_fn=UnyVPSEt1bsWMw6QLRFkeMF8UcObVXv01j8FPYDV+__g@mail.gmail.com>
Date: Wed, 7 Jan 2026 12:31:22 +0100
From: Alexander Potapenko <glider@...gle.com>
To: Andrew Cooper <andrew.cooper3@...rix.com>
Cc: LKML <linux-kernel@...r.kernel.org>, Marco Elver <elver@...gle.com>, 
	Dmitry Vyukov <dvyukov@...gle.com>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, 
	Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org, 
	"H. Peter Anvin" <hpa@...or.com>, Andrew Morton <akpm@...ux-foundation.org>, Jann Horn <jannh@...gle.com>, 
	kasan-dev@...glegroups.com
Subject: Re: [PATCH] x86/kfence: Avoid writing L1TF-vulnerable PTEs

On Tue, Jan 6, 2026 at 7:04 PM Andrew Cooper <andrew.cooper3@...rix.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")
> Tested-by: Marco Elver <elver@...gle.com>
> Signed-off-by: Andrew Cooper <andrew.cooper3@...rix.com>
Reviewed-by: Alexander Potapenko <glider@...gle.com>

>         /*
>          * We need to avoid IPIs, as we may get KFENCE allocations or faults
>          * with interrupts disabled. Therefore, the below is best-effort, and
> @@ -53,11 +77,6 @@ static inline bool kfence_protect_page(unsigned long addr, bool protect)
>          * lazy fault handling takes care of faults after the page is PRESENT.
>          */
Nit: should this comment be moved above before set_pte() or merged wit
the following comment block?