From: Borislav Petkov <bp@kernel.org>
To: X86 ML <x86@kernel.org>
Cc: Nikunj A Dadhania <nikunj@amd.com>,
LKML <linux-kernel@vger.kernel.org>,
"Borislav Petkov (AMD)" <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
stable@kernel.org
Subject: [PATCH 2/4] x86/cpu: Remove X86_CR4_FRED from the CR4 pinned bits mask
Date: Fri, 20 Mar 2026 12:54:15 +0100 [thread overview]
Message-ID: <20260320115417.4156-3-bp@kernel.org> (raw)
In-Reply-To: <20260320115417.4156-1-bp@kernel.org>
From: "Borislav Petkov (AMD)" <bp@alien8.de>
Commit in Fixes added the FRED CR4 bit to the CR4 pinned bits mask so
that whenever something else modifies CR4, that bit remains set. Which
in itself is a perfectly fine idea.
However, there's an issue when during boot FRED is initialized: first on
the BSP and later on the APs. Thus, there's a window in time when
exceptions cannot be handled.
This becomes particularly nasty when running as SEV-{ES,SNP} or TDX
guests which, when they manage to trigger exceptions during that short
window described above, triple fault due to FRED MSRs not being set up
yet.
See Link tag below for a much more detailed explanation of the
situation.
So, as a result, the commit in that Link URL tried to address this
shortcoming by temporarily disabling CR4 pinning when an AP is not
online yet.
However, that is a problem in itself because in this case, an attack on
the kernel needs to only modify the online bit - a single bit in RW
memory - and then disable CR4 pinning and then disable SM*P, leading to
more and worse things to happen to the system.
So, instead, remove the FRED bit from the CR4 pinning mask, thus
obviating the need to temporarily disable CR4 pinning.
If someone manages to disable FRED when poking at CR4, then
idt_invalidate() would make sure the system would crash'n'burn on the
first exception triggered, which is a much better outcome security-wise.
Fixes: ff45746fbf00 ("x86/cpu: Add X86_CR4_FRED macro")
Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: <stable@kernel.org> # 6.12+
Link: https://lore.kernel.org/r/177385987098.1647592.3381141860481415647.tip-bot2@tip-bot2
---
arch/x86/kernel/cpu/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 7840b224d6a7..c57e8972d30f 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -433,7 +433,7 @@ static __always_inline void setup_lass(struct cpuinfo_x86 *c)
/* These bits should not change their value after CPU init is finished. */
static const unsigned long cr4_pinned_mask = X86_CR4_SMEP | X86_CR4_SMAP | X86_CR4_UMIP |
- X86_CR4_FSGSBASE | X86_CR4_CET | X86_CR4_FRED;
+ X86_CR4_FSGSBASE | X86_CR4_CET;
static DEFINE_STATIC_KEY_FALSE_RO(cr_pinning);
static unsigned long cr4_pinned_bits __ro_after_init;
--
2.51.0
next prev parent reply other threads:[~2026-03-20 11:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 11:54 [PATCH 0/4] x86/CPU: Fix CR4 pinning and FRED in CoCo guests Borislav Petkov
2026-03-20 11:54 ` [PATCH 1/4] x86/cpu: Enable FSGSBASE early in cpu_init_exception_handling() Borislav Petkov
2026-03-20 11:54 ` Borislav Petkov [this message]
2026-03-20 17:49 ` [PATCH 2/4] x86/cpu: Remove X86_CR4_FRED from the CR4 pinned bits mask Sohil Mehta
2026-03-20 11:54 ` [PATCH 3/4] x86/fred: Fix early boot failures on SEV-ES/SNP guests Borislav Petkov
2026-03-20 11:54 ` [PATCH 4/4] x86/cpu: Add comment clarifying CRn pinning Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260320115417.4156-3-bp@kernel.org \
--to=bp@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nikunj@amd.com \
--cc=peterz@infradead.org \
--cc=stable@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox