* [PATCH v2 0/3] x86/mm: TLB flush fixes
@ 2025-06-06 17:10 Rik van Riel
2025-06-06 17:10 ` [PATCH v2 1/3] x86/mm: Fix potential overflow in user_pcid_flush_mask Rik van Riel
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: Rik van Riel @ 2025-06-06 17:10 UTC (permalink / raw)
To: linux-kernel
Cc: kernel-team, dave.hansen, luto, peterz, bp, x86, nadav.amit,
seanjc, tglx, mingo
1) Fix a potential overflow in user_pcid_flush_mask.
I do not think anybody is hitting this in practice,
but they could if they wanted to.
2) Change the early boot initialized value of invlpgb_count_max
to 1, to avoid an infinite loop when...
3) Having cpa_flush() call flush_kernel_range(), which results
in the INVPLGB code being called very early at boot time.
v2:
- changelog improvements (Dave Hansen)
- get rid of #ifdefs in .c files (Dave Hansen)
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH v2 1/3] x86/mm: Fix potential overflow in user_pcid_flush_mask
2025-06-06 17:10 [PATCH v2 0/3] x86/mm: TLB flush fixes Rik van Riel
@ 2025-06-06 17:10 ` Rik van Riel
2025-06-06 18:50 ` Dave Hansen
2025-06-06 17:10 ` [PATCH v2 2/3] x86/mm: Fix early boot use of INVPLGB Rik van Riel
2025-06-06 17:10 ` [PATCH v2 3/3] x86/mm: Change cpa_flush() to call flush_kernel_range() directly Rik van Riel
2 siblings, 1 reply; 5+ messages in thread
From: Rik van Riel @ 2025-06-06 17:10 UTC (permalink / raw)
To: linux-kernel
Cc: kernel-team, dave.hansen, luto, peterz, bp, x86, nadav.amit,
seanjc, tglx, mingo, Rik van Riel, Rik van Riel, stable
From: Rik van Riel <riel@meta.com>
Currently no system with AMD INVLPGB support requires the page table
isolation mitigation. However, people could still enable PTI manually,
or a vulnerability could be found in the future that makes PTI useful
on certain AMD CPUs.
The combination of PTI and broadcast TLB flush has a problem:
- invalidate_user_asid() sets a bit corresponding to the process PCID in user_pcid_flush_mask
- SWITCH_TO_USER_CR3 tests and clears a bit corresponding to the process PCID in user_pcid_flush_mask
When using only ASIDs 0-5 this does not cause any issues,
because only PCID numbers 1-6 ever get used.
However, with broadcast TLB flushing PCID numbers up to 2048
can be used, leading to an overflow of the user_pcid_flush_mask,
if a system using INVLPGB is booted with the pti=on option.
Enlarge user_pcid_flush_mask to fit the PCID numbers that can be present
when using broadcast TLB flushing. This takes up 256 or 512 bytes per CPU,
depending on whether or not page table isolation is built into the kernel.
Signed-off-by: Rik van Riel <riel@surriel.com>
Fixes: c3ed3f5b2550 x86/mm: userspace & pageout flushing using Intel RAR
Cc: stable@kernel.org
---
arch/x86/include/asm/tlbflush.h | 49 +++++++++++++++++++++++++++------
arch/x86/mm/tlb.c | 22 +--------------
2 files changed, 42 insertions(+), 29 deletions(-)
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index e9b81876ebe4..401e93958022 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -23,6 +23,40 @@ void __flush_tlb_all(void);
#define TLB_FLUSH_ALL -1UL
#define TLB_GENERATION_INVALID 0
+/*
+ * When enabled, MITIGATION_PAGE_TABLE_ISOLATION consumes a single bit for
+ * user/kernel switches
+ */
+#ifdef CONFIG_MITIGATION_PAGE_TABLE_ISOLATION
+# define PTI_CONSUMED_PCID_BITS 1
+#else
+# define PTI_CONSUMED_PCID_BITS 0
+#endif
+
+#define CR3_AVAIL_PCID_BITS (X86_CR3_PCID_BITS - PTI_CONSUMED_PCID_BITS)
+
+/*
+ * ASIDs are zero-based: 0->MAX_AVAIL_ASID are valid. -1 below to account
+ * for them being zero-based. Another -1 is because PCID 0 is reserved for
+ * use by non-PCID-aware users.
+ */
+#define MAX_ASID_AVAILABLE ((1 << CR3_AVAIL_PCID_BITS) - 2)
+
+/*
+ * With page table isolation, the user_pcid_flush_mask is used to indicate
+ * that the TLB for a process needs to be flushed when switching to user
+ * space. Broadcast TLB flushing uses more PCIDs, and a larger bitmap.
+ */
+#ifdef CONFIG_MITIGATION_PAGE_TABLE_ISOLATION
+# ifdef CONFIG_BROADCAST_TLB_FLUSH
+# define CR3_AVAIL_PCID_LONGS ((1 << CR3_AVAIL_PCID_BITS) / BITS_PER_LONG)
+# else
+# define CR3_AVAIL_PCID_LONGS 1
+# endif
+#else
+# define CR3_AVAIL_PCID_LONGS 0
+#endif
+
void cr4_update_irqsoff(unsigned long set, unsigned long clear);
unsigned long cr4_read_shadow(void);
@@ -115,14 +149,6 @@ struct tlb_state {
*/
u8 lam;
#endif
-
- /*
- * Mask that contains TLB_NR_DYN_ASIDS+1 bits to indicate
- * the corresponding user PCID needs a flush next time we
- * switch to it; see SWITCH_TO_USER_CR3.
- */
- unsigned short user_pcid_flush_mask;
-
/*
* Access to this CR4 shadow and to H/W CR4 is protected by
* disabling interrupts when modifying either one.
@@ -149,6 +175,13 @@ struct tlb_state {
* context 0.
*/
struct tlb_context ctxs[TLB_NR_DYN_ASIDS];
+
+ /*
+ * Mask that contains TLB_NR_DYN_ASIDS+1 bits to indicate
+ * the corresponding user PCID needs a flush next time we
+ * switch to it; see SWITCH_TO_USER_CR3.
+ */
+ unsigned long user_pcid_flush_mask[CR3_AVAIL_PCID_LONGS];
};
DECLARE_PER_CPU_ALIGNED(struct tlb_state, cpu_tlbstate);
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 39f80111e6f1..fceec13a05c1 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -90,25 +90,6 @@
*
*/
-/*
- * When enabled, MITIGATION_PAGE_TABLE_ISOLATION consumes a single bit for
- * user/kernel switches
- */
-#ifdef CONFIG_MITIGATION_PAGE_TABLE_ISOLATION
-# define PTI_CONSUMED_PCID_BITS 1
-#else
-# define PTI_CONSUMED_PCID_BITS 0
-#endif
-
-#define CR3_AVAIL_PCID_BITS (X86_CR3_PCID_BITS - PTI_CONSUMED_PCID_BITS)
-
-/*
- * ASIDs are zero-based: 0->MAX_AVAIL_ASID are valid. -1 below to account
- * for them being zero-based. Another -1 is because PCID 0 is reserved for
- * use by non-PCID-aware users.
- */
-#define MAX_ASID_AVAILABLE ((1 << CR3_AVAIL_PCID_BITS) - 2)
-
/*
* Given @asid, compute kPCID
*/
@@ -557,8 +538,7 @@ static inline void invalidate_user_asid(u16 asid)
if (!static_cpu_has(X86_FEATURE_PTI))
return;
- __set_bit(kern_pcid(asid),
- (unsigned long *)this_cpu_ptr(&cpu_tlbstate.user_pcid_flush_mask));
+ __set_bit(kern_pcid(asid), this_cpu_ptr(&cpu_tlbstate.user_pcid_flush_mask[0]));
}
static void load_new_mm_cr3(pgd_t *pgdir, u16 new_asid, unsigned long lam,
--
2.49.0
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH v2 2/3] x86/mm: Fix early boot use of INVPLGB
2025-06-06 17:10 [PATCH v2 0/3] x86/mm: TLB flush fixes Rik van Riel
2025-06-06 17:10 ` [PATCH v2 1/3] x86/mm: Fix potential overflow in user_pcid_flush_mask Rik van Riel
@ 2025-06-06 17:10 ` Rik van Riel
2025-06-06 17:10 ` [PATCH v2 3/3] x86/mm: Change cpa_flush() to call flush_kernel_range() directly Rik van Riel
2 siblings, 0 replies; 5+ messages in thread
From: Rik van Riel @ 2025-06-06 17:10 UTC (permalink / raw)
To: linux-kernel
Cc: kernel-team, dave.hansen, luto, peterz, bp, x86, nadav.amit,
seanjc, tglx, mingo, Rik van Riel, stable
The INVLPGB instruction has limits on how many pages it can invalidate
at once. That limit is enumerated in CPUID, read by the kernel, and
stored in 'invpgb_count_max'. Ranged invalidation, like
invlpgb_kernel_range_flush() break up their invalidations so
that they do not exceed the limit.
However, early boot code currently attempts to do ranged
invalidation before populating 'invlpgb_count_max'. There is a
for loop which is basically:
for (...; addr < end; addr += invlpgb_count_max*PAGE_SIZE)
If invlpgb_kernel_range_flush is called before the kernel has read
the value of invlpgb_count_max from the hardware, the normally
bounded loop can become an infinite loop if invlpgb_count_max is
initialized to zero.
Fix that issue by initializing invlpgb_count_max to 1.
This way INVPLGB at early boot time will be a little bit slower
than normal (with initialized invplgb_count_max), and not an
instant hang at bootup time.
Signed-off-by: Rik van Riel <riel@surriel.com>
Fixes: b7aa05cbdc52 ("x86/mm: Add INVLPGB support code")
Cc: stable@kernel.org
---
arch/x86/kernel/cpu/amd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 93da466dfe2c..b2ad8d13211a 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -31,7 +31,7 @@
#include "cpu.h"
-u16 invlpgb_count_max __ro_after_init;
+u16 invlpgb_count_max __ro_after_init = 1;
static inline int rdmsrq_amd_safe(unsigned msr, u64 *p)
{
--
2.49.0
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH v2 3/3] x86/mm: Change cpa_flush() to call flush_kernel_range() directly
2025-06-06 17:10 [PATCH v2 0/3] x86/mm: TLB flush fixes Rik van Riel
2025-06-06 17:10 ` [PATCH v2 1/3] x86/mm: Fix potential overflow in user_pcid_flush_mask Rik van Riel
2025-06-06 17:10 ` [PATCH v2 2/3] x86/mm: Fix early boot use of INVPLGB Rik van Riel
@ 2025-06-06 17:10 ` Rik van Riel
2 siblings, 0 replies; 5+ messages in thread
From: Rik van Riel @ 2025-06-06 17:10 UTC (permalink / raw)
To: linux-kernel
Cc: kernel-team, dave.hansen, luto, peterz, bp, x86, nadav.amit,
seanjc, tglx, mingo, Yu-cheng Yu, Rik van Riel
From: Yu-cheng Yu <yu-cheng.yu@intel.com>
The function cpa_flush() calls __flush_tlb_one_kernel() and
flush_tlb_all().
Replacing that with a call to flush_tlb_kernel_range() allows
cpa_flush() to make use of INVLPGB or RAR without any additional
changes.
Initialize invlpgb_count_max to 1, since flush_tlb_kernel_range()
can now be called before invlpgb_count_max has been initialized
to the value read from CPUID.
[riel: remove now unused __cpa_flush_tlb]
Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Signed-off-by: Rik van Riel <riel@surriel.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
---
arch/x86/mm/pat/set_memory.c | 20 +++++++-------------
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
index 30ab4aced761..1da32261bc11 100644
--- a/arch/x86/mm/pat/set_memory.c
+++ b/arch/x86/mm/pat/set_memory.c
@@ -399,15 +399,6 @@ static void cpa_flush_all(unsigned long cache)
on_each_cpu(__cpa_flush_all, (void *) cache, 1);
}
-static void __cpa_flush_tlb(void *data)
-{
- struct cpa_data *cpa = data;
- unsigned int i;
-
- for (i = 0; i < cpa->numpages; i++)
- flush_tlb_one_kernel(fix_addr(__cpa_addr(cpa, i)));
-}
-
static int collapse_large_pages(unsigned long addr, struct list_head *pgtables);
static void cpa_collapse_large_pages(struct cpa_data *cpa)
@@ -444,6 +435,7 @@ static void cpa_collapse_large_pages(struct cpa_data *cpa)
static void cpa_flush(struct cpa_data *cpa, int cache)
{
+ unsigned long start, end;
unsigned int i;
BUG_ON(irqs_disabled() && !early_boot_irqs_disabled);
@@ -453,10 +445,12 @@ static void cpa_flush(struct cpa_data *cpa, int cache)
goto collapse_large_pages;
}
- if (cpa->force_flush_all || cpa->numpages > tlb_single_page_flush_ceiling)
- flush_tlb_all();
- else
- on_each_cpu(__cpa_flush_tlb, cpa, 1);
+ start = fix_addr(__cpa_addr(cpa, 0));
+ end = fix_addr(__cpa_addr(cpa, cpa->numpages));
+ if (cpa->force_flush_all)
+ end = TLB_FLUSH_ALL;
+
+ flush_tlb_kernel_range(start, end);
if (!cache)
goto collapse_large_pages;
--
2.49.0
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2 1/3] x86/mm: Fix potential overflow in user_pcid_flush_mask
2025-06-06 17:10 ` [PATCH v2 1/3] x86/mm: Fix potential overflow in user_pcid_flush_mask Rik van Riel
@ 2025-06-06 18:50 ` Dave Hansen
0 siblings, 0 replies; 5+ messages in thread
From: Dave Hansen @ 2025-06-06 18:50 UTC (permalink / raw)
To: Rik van Riel, linux-kernel
Cc: kernel-team, dave.hansen, luto, peterz, bp, x86, nadav.amit,
seanjc, tglx, mingo, Rik van Riel, stable
On 6/6/25 10:10, Rik van Riel wrote:
> +/*
> + * With page table isolation, the user_pcid_flush_mask is used to indicate
> + * that the TLB for a process needs to be flushed when switching to user
> + * space. Broadcast TLB flushing uses more PCIDs, and a larger bitmap.
> + */
> +#ifdef CONFIG_MITIGATION_PAGE_TABLE_ISOLATION
> +# ifdef CONFIG_BROADCAST_TLB_FLUSH
> +# define CR3_AVAIL_PCID_LONGS ((1 << CR3_AVAIL_PCID_BITS) / BITS_PER_LONG)
> +# else
> +# define CR3_AVAIL_PCID_LONGS 1
> +# endif
> +#else
> +# define CR3_AVAIL_PCID_LONGS 0
> +#endif
Just so nobody goes and applies this...
I don't like how this looks. I'd much rather have the code be
concentrating on *bits* of ASID space rather than longs. I'm going to
rework this a bit.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-06-06 18:50 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-06-06 17:10 [PATCH v2 0/3] x86/mm: TLB flush fixes Rik van Riel
2025-06-06 17:10 ` [PATCH v2 1/3] x86/mm: Fix potential overflow in user_pcid_flush_mask Rik van Riel
2025-06-06 18:50 ` Dave Hansen
2025-06-06 17:10 ` [PATCH v2 2/3] x86/mm: Fix early boot use of INVPLGB Rik van Riel
2025-06-06 17:10 ` [PATCH v2 3/3] x86/mm: Change cpa_flush() to call flush_kernel_range() directly Rik van Riel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®