[PATCH] x86/cpu: Disable FRED when PTI is forced on

[PATCH] x86/cpu: Disable FRED when PTI is forced on

[Dave Hansen]

From: Dave Hansen <dave.hansen@linux.intel.com>

FRED and PTI were never intended to work together. No FRED hardware is
vulnerable to Meltdown and all of it should have LASS anyway.
Nevertheless, if you boot a system with pti=on and fred=on, the kernel
tries to do what is asked of it and dies a horrible death on the first
attempt to run userspace (since it never switches to the user page
tables).

Disable FRED when PTI is forced on, and print a warning about it.

A quick brain dump about what a FRED+PTI implementation would look like
is below. I'm not sure it would make any sense to do it, but never say
never. All I know is that it's way too complicated to be worth it today.

<brain dump>
The SWITCH_TO_USER/KERNEL_CR3 bits are simple to fix (or at least we
have the assembly tools to do it already), as is sticking the FRED entry
text in .entry.text (it's not in there today).

The nasty part is the stacks. Today, the CPU pops into the kernel on
MSR_IA32_FRED_RSP0 which is normal old kernel memory and not mapped to
userspace. The hardware pushes gunk on to MSR_IA32_FRED_RSP0, which is
currently the task stacks. MSR_IA32_FRED_RSP0 would need to point
elsewhere, probably cpu_entry_stack(). Then, start playing games with
stacks on entry/exit, including copying gunk to and from the task stack.

While I'd *like* to have PTI everywhere, I'm not sure it's worth mucking
up the FRED code with PTI kludges. If a user wants fast entry/exit, they
use FRED. If you want PTI (and sekuritay), you certainly don't care
about fast entry and FRED isn't going to help you *all* that much, so
you can just stay with the IDT.

Plus, FRED hardware should have LASS which gives you a similar security
profile to PTI without the CR3 munging.
</brain dump>

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reported-by: Gayatri Kammela <Gayatri.Kammela@amd.com>
Cc: stable@vger.kernel.org
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: x86@kernel.org
Cc: "H. Peter Anvin" <hpa@zytor.com>
---

 b/arch/x86/mm/pti.c |    5 +++++
 1 file changed, 5 insertions(+)

diff -puN arch/x86/mm/pti.c~fred-vs-kpti arch/x86/mm/pti.c
--- a/arch/x86/mm/pti.c~fred-vs-kpti	2026-04-21 08:37:01.124709928 -0700
+++ b/arch/x86/mm/pti.c	2026-04-21 08:41:11.219700206 -0700
@@ -105,6 +105,11 @@ void __init pti_check_boottime_disable(v
 		pr_debug("PTI enabled, disabling INVLPGB\n");
 		setup_clear_cpu_cap(X86_FEATURE_INVLPGB);
 	}
+
+	if (cpu_feature_enabled(X86_FEATURE_FRED)) {
+		pr_debug("PTI enabled, disabling FRED\n");
+		setup_clear_cpu_cap(X86_FEATURE_FRED);
+	}
 }
 
 static int __init pti_parse_cmdline(char *arg)
_

Re: [PATCH] x86/cpu: Disable FRED when PTI is forced on

[Borislav Petkov]

On Tue, Apr 21, 2026 at 09:31:36AM -0700, Dave Hansen wrote:
> 
> From: Dave Hansen <dave.hansen@linux.intel.com>
> 
> FRED and PTI were never intended to work together. No FRED hardware is
> vulnerable to Meltdown and all of it should have LASS anyway.
> Nevertheless, if you boot a system with pti=on and fred=on, the kernel
> tries to do what is asked of it and dies a horrible death on the first
> attempt to run userspace (since it never switches to the user page
> tables).
> 
> Disable FRED when PTI is forced on, and print a warning about it.
> 
> A quick brain dump about what a FRED+PTI implementation would look like
> is below. I'm not sure it would make any sense to do it, but never say
> never. All I know is that it's way too complicated to be worth it today.

... and if anyone attempts it, they better justify the effort and overhead.

> <brain dump>
> The SWITCH_TO_USER/KERNEL_CR3 bits are simple to fix (or at least we
> have the assembly tools to do it already), as is sticking the FRED entry
> text in .entry.text (it's not in there today).
> 
> The nasty part is the stacks. Today, the CPU pops into the kernel on
> MSR_IA32_FRED_RSP0 which is normal old kernel memory and not mapped to
> userspace. The hardware pushes gunk on to MSR_IA32_FRED_RSP0, which is
> currently the task stacks. MSR_IA32_FRED_RSP0 would need to point
> elsewhere, probably cpu_entry_stack(). Then, start playing games with
> stacks on entry/exit, including copying gunk to and from the task stack.
> 
> While I'd *like* to have PTI everywhere, I'm not sure it's worth mucking
> up the FRED code with PTI kludges. If a user wants fast entry/exit, they
> use FRED. If you want PTI (and sekuritay), you certainly don't care
> about fast entry and FRED isn't going to help you *all* that much, so
> you can just stay with the IDT.
> 
> Plus, FRED hardware should have LASS which gives you a similar security
> profile to PTI without the CR3 munging.
> </brain dump>
> 
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> Reported-by: Gayatri Kammela <Gayatri.Kammela@amd.com>
> Cc: stable@vger.kernel.org
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: x86@kernel.org
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> ---

Yap, let's do the simplest thing first.

Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de>

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] x86/cpu: Disable FRED when PTI is forced on

[Maciej Wieczor-Retman]

Tested on a Panther Lake system. After applying the patch, FRED gets disabled
when 'pti=on' is used. No other issues were observed.

Tested-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>

-- 
Kind regards
Maciej Wieczór-Retman

[tip: x86/urgent] x86/cpu: Disable FRED when PTI is forced on

[tip-bot2 for Dave Hansen]

The following commit has been merged into the x86/urgent branch of tip:

Commit-ID:     932d922285ef4d0d655a6f5def2779ae86ca0d73
Gitweb:        https://git.kernel.org/tip/932d922285ef4d0d655a6f5def2779ae86ca0d73
Author:        Dave Hansen <dave.hansen@linux.intel.com>
AuthorDate:    Tue, 21 Apr 2026 09:31:36 -07:00
Committer:     Dave Hansen <dave.hansen@linux.intel.com>
CommitterDate: Tue, 21 Apr 2026 15:11:40 -07:00

x86/cpu: Disable FRED when PTI is forced on

FRED and PTI were never intended to work together. No FRED hardware is
vulnerable to Meltdown and all of it should have LASS anyway.
Nevertheless, if you boot a system with pti=on and fred=on, the kernel
tries to do what is asked of it and dies a horrible death on the first
attempt to run userspace (since it never switches to the user page
tables).

Disable FRED when PTI is forced on, and print a warning about it.

A quick brain dump about what a FRED+PTI implementation would look like
is below. I'm not sure it would make any sense to do it, but never say
never. All I know is that it's way too complicated to be worth it today.

<brain dump>
The SWITCH_TO_USER/KERNEL_CR3 bits are simple to fix (or at least we
have the assembly tools to do it already), as is sticking the FRED entry
text in .entry.text (it's not in there today).

The nasty part is the stacks. Today, the CPU pops into the kernel on
MSR_IA32_FRED_RSP0 which is normal old kernel memory and not mapped to
userspace. The hardware pushes gunk on to MSR_IA32_FRED_RSP0, which is
currently the task stacks. MSR_IA32_FRED_RSP0 would need to point
elsewhere, probably cpu_entry_stack(). Then, start playing games with
stacks on entry/exit, including copying gunk to and from the task stack.

While I'd *like* to have PTI everywhere, I'm not sure it's worth mucking
up the FRED code with PTI kludges. If a user wants fast entry/exit, they
use FRED. If you want PTI (and sekuritay), you certainly don't care
about fast entry and FRED isn't going to help you *all* that much, so
you can just stay with the IDT.

Plus, FRED hardware should have LASS which gives you a similar security
profile to PTI without the CR3 munging.
</brain dump>

Reported-by: Gayatri Kammela <Gayatri.Kammela@amd.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de>
Tested-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
Cc:stable@vger.kernel.org
Link: https://patch.msgid.link/20260421163136.E7C6788A@davehans-spike.ostc.intel.com
---
 arch/x86/mm/pti.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
index f7546e9..631f037 100644
--- a/arch/x86/mm/pti.c
+++ b/arch/x86/mm/pti.c
@@ -105,6 +105,11 @@ void __init pti_check_boottime_disable(void)
 		pr_debug("PTI enabled, disabling INVLPGB\n");
 		setup_clear_cpu_cap(X86_FEATURE_INVLPGB);
 	}
+
+	if (cpu_feature_enabled(X86_FEATURE_FRED)) {
+		pr_debug("PTI enabled, disabling FRED\n");
+		setup_clear_cpu_cap(X86_FEATURE_FRED);
+	}
 }
 
 static int __init pti_parse_cmdline(char *arg)

Re: [PATCH] x86/cpu: Disable FRED when PTI is forced on

[H. Peter Anvin]

On April 21, 2026 9:31:36 AM PDT, Dave Hansen <dave.hansen@linux.intel.com> wrote:
>
>From: Dave Hansen <dave.hansen@linux.intel.com>
>
>FRED and PTI were never intended to work together. No FRED hardware is
>vulnerable to Meltdown and all of it should have LASS anyway.
>Nevertheless, if you boot a system with pti=on and fred=on, the kernel
>tries to do what is asked of it and dies a horrible death on the first
>attempt to run userspace (since it never switches to the user page
>tables).
>
>Disable FRED when PTI is forced on, and print a warning about it.
>
>A quick brain dump about what a FRED+PTI implementation would look like
>is below. I'm not sure it would make any sense to do it, but never say
>never. All I know is that it's way too complicated to be worth it today.
>
><brain dump>
>The SWITCH_TO_USER/KERNEL_CR3 bits are simple to fix (or at least we
>have the assembly tools to do it already), as is sticking the FRED entry
>text in .entry.text (it's not in there today).
>
>The nasty part is the stacks. Today, the CPU pops into the kernel on
>MSR_IA32_FRED_RSP0 which is normal old kernel memory and not mapped to
>userspace. The hardware pushes gunk on to MSR_IA32_FRED_RSP0, which is
>currently the task stacks. MSR_IA32_FRED_RSP0 would need to point
>elsewhere, probably cpu_entry_stack(). Then, start playing games with
>stacks on entry/exit, including copying gunk to and from the task stack.
>
>While I'd *like* to have PTI everywhere, I'm not sure it's worth mucking
>up the FRED code with PTI kludges. If a user wants fast entry/exit, they
>use FRED. If you want PTI (and sekuritay), you certainly don't care
>about fast entry and FRED isn't going to help you *all* that much, so
>you can just stay with the IDT.
>
>Plus, FRED hardware should have LASS which gives you a similar security
>profile to PTI without the CR3 munging.
></brain dump>
>
>Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
>Reported-by: Gayatri Kammela <Gayatri.Kammela@amd.com>
>Cc: stable@vger.kernel.org
>Cc: Andy Lutomirski <luto@kernel.org>
>Cc: Peter Zijlstra <peterz@infradead.org>
>Cc: Thomas Gleixner <tglx@kernel.org>
>Cc: Ingo Molnar <mingo@redhat.com>
>Cc: Borislav Petkov <bp@alien8.de>
>Cc: x86@kernel.org
>Cc: "H. Peter Anvin" <hpa@zytor.com>
>---
>
> b/arch/x86/mm/pti.c |    5 +++++
> 1 file changed, 5 insertions(+)
>
>diff -puN arch/x86/mm/pti.c~fred-vs-kpti arch/x86/mm/pti.c
>--- a/arch/x86/mm/pti.c~fred-vs-kpti	2026-04-21 08:37:01.124709928 -0700
>+++ b/arch/x86/mm/pti.c	2026-04-21 08:41:11.219700206 -0700
>@@ -105,6 +105,11 @@ void __init pti_check_boottime_disable(v
> 		pr_debug("PTI enabled, disabling INVLPGB\n");
> 		setup_clear_cpu_cap(X86_FEATURE_INVLPGB);
> 	}
>+
>+	if (cpu_feature_enabled(X86_FEATURE_FRED)) {
>+		pr_debug("PTI enabled, disabling FRED\n");
>+		setup_clear_cpu_cap(X86_FEATURE_FRED);
>+	}
> }
> 
> static int __init pti_parse_cmdline(char *arg)
>_

Acked-by: H. Peter Anvin (Intel) <hpa@zytor.com>

Re: [PATCH] x86/cpu: Disable FRED when PTI is forced on

[Andrew Cooper]

> FRED and PTI were never intended to work together. No FRED hardware is
> vulnerable to Meltdown and all of it should have LASS anyway.

Careful.  All Intel parts maybe, but Intel is not the only vendor
implementing FRED.

~Andrew

Re: [PATCH] x86/cpu: Disable FRED when PTI is forced on

[H. Peter Anvin]

On April 22, 2026 5:08:27 AM PDT, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> FRED and PTI were never intended to work together. No FRED hardware is
>> vulnerable to Meltdown and all of it should have LASS anyway.
>
>Careful.  All Intel parts maybe, but Intel is not the only vendor
>implementing FRED.
>
>~Andrew

We know. AMD are aware of the tradeoff as well and presumably have their own approach(es) to avoid these problems.