x86/kfence: Avoid writing L1TF-vulnerable PTEs

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

Posted by Andrew Cooper 1 month ago

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@google.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
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.
---
 arch/x86/include/asm/kfence.h | 29 ++++++++++++++++++++++++-----
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/kfence.h b/arch/x86/include/asm/kfence.h
index ff5c7134a37a..acf9ffa1a171 100644
--- a/arch/x86/include/asm/kfence.h
+++ b/arch/x86/include/asm/kfence.h
@@ -42,10 +42,34 @@ static inline bool kfence_protect_page(unsigned long addr, bool protect)
 {
 	unsigned int level;
 	pte_t *pte = lookup_address(addr, &level);
+	pteval_t val;
 
 	if (WARN_ON(!pte || level != PG_LEVEL_4K))
 		return false;
 
+	val = pte_val(*pte);
+
+	/*
+	 * protect requires making the page not-present.  If the PTE is
+	 * already in the right state, there's nothing to do.
+	 */
+	if (protect != !!(val & _PAGE_PRESENT))
+		return true;
+
+	/*
+	 * Otherwise, invert the entire PTE.  This avoids writing out an
+	 * L1TF-vulnerable PTE (not present, without the high address bits
+	 * set).
+	 */
+	set_pte(pte, __pte(~val));
+
+	/*
+	 * If the page was protected (non-present) and we're making it
+	 * present, there is no need to flush the TLB at all.
+	 */
+	if (!protect)
+		return true;
+
 	/*
 	 * 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.
 	 */
 
-	if (protect)
-		set_pte(pte, __pte(pte_val(*pte) & ~_PAGE_PRESENT));
-	else
-		set_pte(pte, __pte(pte_val(*pte) | _PAGE_PRESENT));
-
 	/*
 	 * Flush this CPU's TLB, assuming whoever did the allocation/free is
 	 * likely to continue running on this CPU.

base-commit: 7f98ab9da046865d57c102fd3ca9669a29845f67
-- 
2.39.5

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

Posted by Andrew Morton 1 month ago

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.

>
> ...
>

[REGRESSION] x86_32 boot hang in 6.19-rc7 caused by b505f1944535 ("x86/kfence: avoid writing L1TF-vulnerable PTEs")

Posted by Ryusuke Konishi 1 week, 4 days ago

Hi All,

I am reporting a boot regression in v6.19-rc7 on an x86_32
environment. The kernel hangs immediately after "Booting the kernel"
and does not produce any early console output.

A git bisect identified the following commit as the first bad commit:
b505f1944535 ("x86/kfence: avoid writing L1TF-vulnerable PTEs")

Environment and Config:
- Guest Arch: x86_32  (one of my test VMs)
- Memory Config: # CONFIG_X86_PAE is not set
- KFENCE Config: CONFIG_KFENCE=y
- Host/Hypervisor: x86_64 host running KVM

The system fails to boot at a very early stage. I have confirmed that
reverting commit b505f1944535 on top of v6.19-rc7 completely resolves
the issue, and the kernel boots normally.

Could you please verify if this change is compatible with x86_32
(non-PAE) configurations?
I am happy to provide my full .config or test any potential fixes.

Best regards,
Ryusuke Konishi