From nobody Sat Apr 4 07:47:31 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DEB363AA519 for ; Fri, 20 Mar 2026 11:54:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774007663; cv=none; b=R4+ftSm86cqG+vDGBy7Ouk75w5shhwR87hVakMhj2DedOsShQjkgPY37/FbFDZlHLxhYmxCdZJUNP5uc5jlcJnd+/jpjQdvYiLr/dM6klTk2CnhMlFdkkX80W/T0zCgfpPc2x5qtALaoDEhzO3jkYiYzCtIozrHA6tCyts8cJ5E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774007663; c=relaxed/simple; bh=z43NRHGb+77g/nx7QHI/SfLzvalWf0s45xHjUBa0D4E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BJszeCNlJD9b+cYJTjxHfVkpA0341XE5PEHhFkSgPTVxDjmaeYqAvi5Yi5iM4WCn20h+vdv5OxfcL10oR2A8/ucR9bx2U9Sje1Q+yNEYjk2Q0jTPiYm1rXqMC6EpBaMGuOhQMT5dUgQxkujxwnHA8eHOodSpWsCvU0fxBYPtydY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kApNwq4h; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kApNwq4h" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 370EDC2BCAF; Fri, 20 Mar 2026 11:54:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774007663; bh=z43NRHGb+77g/nx7QHI/SfLzvalWf0s45xHjUBa0D4E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kApNwq4hUwafRHX6oRvk7hRxDxFo6ZVymhpu4zv8toomi4YQYwRUG+vYTPv7dsUVU SjzL34UqU2iWrf1IJyofc+LZfaBsN9LXrfXtk/Nhl3MEYaa3srv8nmyvvk6QA+4zNB G0E93Y8xDcpKNf8E20qv3hVmWuPG0FDOOWW9XquNYKjj2/8YIeK3NzSW+YiMCEUfo3 nZHPkFL4zXghHgx9NfU4zsxIf4s0Dj0cqZgjw2MHvi1qZ4BBN2VlZVOMKrohSXCNQh nWuuR34ShQ0eJVvYSUnDYUablDrLit4jsCuoWt1O0r0IhuH+GUpWoMT0L1wXHGP7e0 ApP7D4hDD+kcg== From: Borislav Petkov To: X86 ML Cc: Nikunj A Dadhania , LKML , Borislav Petkov , Sohil Mehta , stable@kernel.org Subject: [PATCH 1/4] x86/cpu: Enable FSGSBASE early in cpu_init_exception_handling() Date: Fri, 20 Mar 2026 12:54:14 +0100 Message-ID: <20260320115417.4156-2-bp@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260320115417.4156-1-bp@kernel.org> References: <20260320115417.4156-1-bp@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nikunj A Dadhania Move FSGSBASE enablement from identify_cpu() to cpu_init_exception_handling= () to ensure it is enabled before any exceptions can occur on both boot and secondary CPUs. =3D=3D Background =3D=3D Exception entry code (paranoid_entry()) uses ALTERNATIVE patching based on X86_FEATURE_FSGSBASE to decide whether to use RDGSBASE/WRGSBASE instructions or the slower RDMSR/SWAPGS sequence for saving/restoring GSBASE. On boot CPU, ALTERNATIVE patching happens after enabling FSGSBASE in CR4. When the feature is available, the code is permanently patched to use RDGSBASE/WRGSBASE, which require CR4.FSGSBASE=3D1 to execute without trigge= ring =3D=3D Boot Sequence =3D=3D Boot CPU (with CR pinning enabled): trap_init() cpu_init() <- Uses unpatched code (RDMSR/SWAPGS) x2apic_setup() ... arch_cpu_finalize_init() identify_boot_cpu() identify_cpu() cr4_set_bits(X86_CR4_FSGSBASE) # Enables the feature # This becomes part of cr4_pinned_bits ... alternative_instructions() <- Patches code to use RDGSBASE/WRGSBASE Secondary CPUs (with CR pinning enabled): start_secondary() cr4_init() <- Code already patched, CR4.FSGSBASE=3D1 set implicitly via cr4_pinned_bits cpu_init() <- exceptions work because FSGSBASE is already enabled Secondary CPU (with CR pinning disabled): start_secondary() cr4_init() <- Code already patched, CR4.FSGSBASE=3D0 cpu_init() x2apic_setup() rdmsrq(MSR_IA32_APICBASE) <- Triggers #VC in SNP guests exc_vmm_communication() paranoid_entry() <- Uses RDGSBASE with CR4.FSGSBASE=3D0 (patched code) ... ap_starting() identify_secondary_cpu() identify_cpu() cr4_set_bits(X86_CR4_FSGSBASE) <- Enables the feature, which is too late =3D=3D CR Pinning =3D=3D Currently, for secondary CPUs, CR4.FSGSBASE is set implicitly through CR-pinning: the boot CPU sets it during identify_cpu(), it becomes part of cr4_pinned_bits, and cr4_init() applies those pinned bits to secondary CPUs. This works but creates an undocumented dependency between cr4_init() and the pinning mechanism. =3D=3D Problem =3D=3D Secondary CPUs boot after alternatives have been applied globally. They execute already-patched paranoid_entry() code that uses RDGSBASE/WRGSBASE instructions, which require CR4.FSGSBASE=3D1. Upcoming changes to CR pinning behavior will break the implicit dependency, causing secondary CPUs to generate #UD. This issue manifests itself on AMD SEV-SNP guests, where the rdmsrq() in x2apic_setup() triggers a #VC exception early during cpu_init(). The #VC handler (exc_vmm_communication()) executes the patched paranoid_entry() pat= h. Without CR4.FSGSBASE enabled, RDGSBASE instructions trigger #UD. =3D=3D Fix =3D=3D Enable FSGSBASE explicitly in cpu_init_exception_handling() before loading exception handlers. This makes the dependency explicit and ensures both boot and secondary CPUs have FSGSBASE enabled before paranoid_entry() executes. Fixes: c82965f9e530 ("x86/entry/64: Handle FSGSBASE enabled paranoid entry/= exit") Reported-by: Borislav Petkov Suggested-by: Sohil Mehta Signed-off-by: Nikunj A Dadhania Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Sohil Mehta Cc: Link: https://patch.msgid.link/20260318075654.1792916-2-nikunj@amd.com --- arch/x86/kernel/cpu/common.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index a8ff4376c286..7840b224d6a7 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -2050,12 +2050,6 @@ static void identify_cpu(struct cpuinfo_x86 *c) setup_umip(c); setup_lass(c); =20 - /* Enable FSGSBASE instructions if available. */ - if (cpu_has(c, X86_FEATURE_FSGSBASE)) { - cr4_set_bits(X86_CR4_FSGSBASE); - elf_hwcap2 |=3D HWCAP2_FSGSBASE; - } - /* * The vendor-specific functions might have changed features. * Now we do "generic changes." @@ -2416,6 +2410,18 @@ void cpu_init_exception_handling(bool boot_cpu) /* GHCB needs to be setup to handle #VC. */ setup_ghcb(); =20 + /* + * On CPUs with FSGSBASE support, paranoid_entry() uses + * ALTERNATIVE-patched RDGSBASE/WRGSBASE instructions. Secondary CPUs + * boot after alternatives are patched globally, so early exceptions + * execute patched code that depends on FSGSBASE. Enable the feature + * before any exceptions occur. + */ + if (cpu_feature_enabled(X86_FEATURE_FSGSBASE)) { + cr4_set_bits(X86_CR4_FSGSBASE); + elf_hwcap2 |=3D HWCAP2_FSGSBASE; + } + if (cpu_feature_enabled(X86_FEATURE_FRED)) { /* The boot CPU has enabled FRED during early boot */ if (!boot_cpu) --=20 2.51.0 From nobody Sat Apr 4 07:47:31 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 12CD63AC0D3 for ; Fri, 20 Mar 2026 11:54:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774007666; cv=none; b=VqSFBQ7PfIM/SJDoYdPqJdLjQxglgyz1SQxgiUWx90+6nUrMKDj+8zDQtO6HMa++jvaH1fQer0RDgToBrNsj7ZeP9md38C2TNpH6iUy5ORlU7Fl2a9ihzhyc0Tas4GpNTMxSUdxpFzUOimBdWgVRuXr9BcBpUYgy5yD2lGNE6CE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774007666; c=relaxed/simple; bh=0Z1sfuIAauEUSKutBrOW/Ex6Rw7OQ1EJkN/wt2i19Ik=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=deDxN0BYzah3Z1f1l19LkmiABEkxO1l77QOcRVFhOdSdOBwCC+nIYdr1aZPoPdFCgY+7WJ2vFpiOmet+kzKbnlXnJT/hESZu+KrPXf+7P1DyZndKPHqREpt7bDKcrH+g+9oSGXU1Smm9AQ34yWQeLiU11C+lvSgM2QItNanezWE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Fg1lHKry; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Fg1lHKry" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 196B2C4CEF7; Fri, 20 Mar 2026 11:54:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774007665; bh=0Z1sfuIAauEUSKutBrOW/Ex6Rw7OQ1EJkN/wt2i19Ik=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Fg1lHKrypaxYMR/YrxIflABnKdPLKh2tZ6uSLK97I9YUlr2z5Tk/T9A98yb7UoyMZ cIvVYQdG/1W54QG96t8PTX2Abl0wJPGgyzxm31HdAHg5FJhbDk3elajs/wvYpUDIZj 00Qy78jflxvbdO0aiv7SmTfk9LPqQ2viAd6Q4qfCFd3chNJep4W6yOxidn1CwKEjle YWNX3d357K2ztXUZetVqY7aJhzl7GVPb9xsb1jgW1ZqlvrE8rmnhw6H7ir1Wo8HfzR cw9aB9U8RPkfm8BSimEGPCJg5skUPiB0SE6FOsdmHCrXPk+Jg+k87K2DqNudzkSLpW /JuxP37kdYqog== From: Borislav Petkov To: X86 ML Cc: Nikunj A Dadhania , LKML , "Borislav Petkov (AMD)" , Dave Hansen , Peter Zijlstra , 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 Message-ID: <20260320115417.4156-3-bp@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260320115417.4156-1-bp@kernel.org> References: <20260320115417.4156-1-bp@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Borislav Petkov (AMD)" 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 Suggested-by: Peter Zijlstra Signed-off-by: Borislav Petkov (AMD) Cc: # 6.12+ Link: https://lore.kernel.org/r/177385987098.1647592.3381141860481415647.ti= p-bot2@tip-bot2 Reviewed-by: Sohil Mehta --- 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_x= 86 *c) =20 /* These bits should not change their value after CPU init is finished. */ static const unsigned long cr4_pinned_mask =3D 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; =20 --=20 2.51.0 From nobody Sat Apr 4 07:47:31 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CE1733AC0E3 for ; Fri, 20 Mar 2026 11:54:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774007667; cv=none; b=Y6h0oq56YJPCkl5P6Yu9rNLlqDJ9rCU5qz9HMGjAqh3Ypk3VQ1hH6dVhIktY/CzbpsnBScRElI/J/pjM/jAaiXLgh+QB97QrKZzNKq/G9YON6uQtdmEAxTp661gUAiJgsqN5F+ZWlHIRq8c0fUwkoFxjkQaeE++GwH1VqwsT+sI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774007667; c=relaxed/simple; bh=Y/aaIKfTme5283X74Uxei3bvshkBl4zu7/vkryT3i+g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LMJrHJaws7rliC5ICpapMXhTC4vH6fsUjD4PlBZARWEJmBIfYE0kWKyFV9Nwv0HUaxqFW4MbX0HXOdxg3HnWzMYFvxKCeT9oPjtEIcDdHcP7shiLUdqrPgF0XwKCVAGSEfYifQyma/8d9AEVB5aBOdI8H/c6dGnp676iQNJXyZ4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sslQZj9e; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sslQZj9e" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28753C2BCB0; Fri, 20 Mar 2026 11:54:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774007667; bh=Y/aaIKfTme5283X74Uxei3bvshkBl4zu7/vkryT3i+g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sslQZj9ej6cQNWI15W++4/+uiXS2S+NfXy47JAzo96OsMnqdmSRTB8Il7J52evBYz TkF5Gpd6oHibO8b90Kl4tg5kE2SqJk+v8HSJknStFCpayr+TDhqDBX7jFmrPcF+02f Kg0T4u+ybQd8nQM4zA2aQe1x33+cF+HFj1A2VZu4yYpWwHAslJVc0z8LSXTQvwzl2o /OKDccfiYHGDq7TnR6/wTZbHVapGHg4UbnQ1G1+GrNsl4Cp2drDiSq7NJomDBkQyJ9 fZ8YasazghLE7uRGZDPrSw+e1MjeC4Fk0t0pEkL7QnyNajtaeJHO9XGkc0b8mqF5yI lurGEnCiyy93w== From: Borislav Petkov To: X86 ML Cc: Nikunj A Dadhania , LKML , "Borislav Petkov (AMD)" , Tom Lendacky , stable@kernel.org Subject: [PATCH 3/4] x86/fred: Fix early boot failures on SEV-ES/SNP guests Date: Fri, 20 Mar 2026 12:54:16 +0100 Message-ID: <20260320115417.4156-4-bp@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260320115417.4156-1-bp@kernel.org> References: <20260320115417.4156-1-bp@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nikunj A Dadhania FRED-enabled SEV-(ES,SNP) guests fail to boot due to the following issues in the early boot sequence: * FRED does not have a #VC exception handler in the dispatch logic * Early FRED #VC exceptions attempt to use uninitialized per-CPU GHCBs instead of boot_ghcb Add X86_TRAP_VC case to fred_hwexc() with a new exc_vmm_communication() function that provides the unified entry point FRED requires, dispatching to existing user/kernel handlers based on privilege level. The function is already declared via DECLARE_IDTENTRY_VC(). Fix early GHCB access by falling back to boot_ghcb in __sev_{get,put}_ghcb() when per-CPU GHCBs are not yet initialized. Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code") Signed-off-by: Nikunj A Dadhania Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Tom Lendacky Cc: # 6.12+ Link: https://patch.msgid.link/20260318075654.1792916-4-nikunj@amd.com --- arch/x86/coco/sev/noinstr.c | 6 ++++++ arch/x86/entry/entry_fred.c | 14 ++++++++++++++ 2 files changed, 20 insertions(+) diff --git a/arch/x86/coco/sev/noinstr.c b/arch/x86/coco/sev/noinstr.c index 9d94aca4a698..5afd663a1c21 100644 --- a/arch/x86/coco/sev/noinstr.c +++ b/arch/x86/coco/sev/noinstr.c @@ -121,6 +121,9 @@ noinstr struct ghcb *__sev_get_ghcb(struct ghcb_state *= state) =20 WARN_ON(!irqs_disabled()); =20 + if (!sev_cfg.ghcbs_initialized) + return boot_ghcb; + data =3D this_cpu_read(runtime_data); ghcb =3D &data->ghcb_page; =20 @@ -164,6 +167,9 @@ noinstr void __sev_put_ghcb(struct ghcb_state *state) =20 WARN_ON(!irqs_disabled()); =20 + if (!sev_cfg.ghcbs_initialized) + return; + data =3D this_cpu_read(runtime_data); ghcb =3D &data->ghcb_page; =20 diff --git a/arch/x86/entry/entry_fred.c b/arch/x86/entry/entry_fred.c index 88c757ac8ccd..fbe2d10dd737 100644 --- a/arch/x86/entry/entry_fred.c +++ b/arch/x86/entry/entry_fred.c @@ -177,6 +177,16 @@ static noinstr void fred_extint(struct pt_regs *regs) } } =20 +#ifdef CONFIG_AMD_MEM_ENCRYPT +noinstr void exc_vmm_communication(struct pt_regs *regs, unsigned long err= or_code) +{ + if (user_mode(regs)) + return user_exc_vmm_communication(regs, error_code); + else + return kernel_exc_vmm_communication(regs, error_code); +} +#endif + static noinstr void fred_hwexc(struct pt_regs *regs, unsigned long error_c= ode) { /* Optimize for #PF. That's the only exception which matters performance = wise */ @@ -207,6 +217,10 @@ static noinstr void fred_hwexc(struct pt_regs *regs, u= nsigned long error_code) #ifdef CONFIG_X86_CET case X86_TRAP_CP: return exc_control_protection(regs, error_code); #endif +#ifdef CONFIG_AMD_MEM_ENCRYPT + case X86_TRAP_VC: return exc_vmm_communication(regs, error_code); +#endif + default: return fred_bad_type(regs, error_code); } =20 --=20 2.51.0 From nobody Sat Apr 4 07:47:31 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9DCF23ACA4A for ; Fri, 20 Mar 2026 11:54:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774007669; cv=none; b=YGiiaSsjIDzVU4FhOsgnPev+LnHWYxETYR9XtcjkZhg+a/48cqp85U8N0UzS1JFpOrEKxiLDDyah87LobcVBVDOctzbhhG5HlrGpuHWEpNBnPNWIIAETLW0JaH77YBvyrHRHdDQUcg6kpYEBMdVn9pshfGLmlszNwZgZnWYsouo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774007669; c=relaxed/simple; bh=ru9VTnMqOkY6IbxTJnIEh/kXclIdjI/M0uE98QSk9TU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Cd81UQ4sRpz0TYavSh5/LmKs4rIpuswAHuRMx/4QddXSvq7lUwIHnRz7h0miVuS60zhAniR+dLULwVL/xPzY3xaSqTtc/isku3l7UHf/Pdl0wqPWOuD3LLgqiMR5JEu0LUrRw6IxLptMYkQPF1LFmpBoyfQOVLBZqOYL9B6lTLY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=uzg1//rd; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="uzg1//rd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0AA41C2BC9E; Fri, 20 Mar 2026 11:54:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774007669; bh=ru9VTnMqOkY6IbxTJnIEh/kXclIdjI/M0uE98QSk9TU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uzg1//rd/5MgdK6hCK/XiqaxqAYM9E0rhcmdEVl3fYJ//wuO/hcdx3Ekk8A4ujfeP jGAFxHZ2BZvmFuLIZ99mbX3s6EbKvM1wJNDhK//mywZqJQ11BTUuEx3Fy3HGBFRQzt cAdQ4/StDuNbmflHD5/6VwxeSKAQplIE0wuCDQJwngVaszHTPsBr0KlTPN0PfPFOau BJJdP8V92f0p3uxzIaH9+WKgM5Dw4t5y0bL9CeUzdCw28zD+cEd0vQyeE0al8SQTBo vZHDymXst5bdKP7zGOIjLixQ5js/4rB2o9+VayJN9LAs4Ox26xdYTYiBIUdHYtfXK7 jOY5jE7u43DDg== From: Borislav Petkov To: X86 ML Cc: Nikunj A Dadhania , LKML , Peter Zijlstra , "Borislav Petkov (AMD)" Subject: [PATCH 4/4] x86/cpu: Add comment clarifying CRn pinning Date: Fri, 20 Mar 2026 12:54:17 +0100 Message-ID: <20260320115417.4156-5-bp@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260320115417.4156-1-bp@kernel.org> References: <20260320115417.4156-1-bp@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Peter Zijlstra To avoid future confusion on the purpose and design of the CRn pinning code. Also note that if the attacker controls page-tables, the CRn bits lose much= of the attraction anyway. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov (AMD) Link: https://patch.msgid.link/20260320092521.GG3739106@noisy.programming.k= icks-ass.net --- arch/x86/kernel/cpu/common.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index c57e8972d30f..ec0670114efa 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -434,6 +434,19 @@ 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 =3D X86_CR4_SMEP | X86_CR4_SMAP= | X86_CR4_UMIP | X86_CR4_FSGSBASE | X86_CR4_CET; + +/* + * The CR pinning protects against ROP on the 'mov %reg, %CRn' instruction= (s). + * Since you can ROP directly to these instructions (barring shadow stack), + * any protection must follow immediately and unconditionally after that. + * + * Specifically, the CR[04] write functions below will have the value + * validation controlled by the @cr_pinning static_branch which is + * __ro_after_init, just like the cr4_pinned_bits value. + * + * Once set, an attacker will have to defeat page-tables to get around the= se + * restrictions. Which is a much bigger ask than 'simple' ROP. + */ static DEFINE_STATIC_KEY_FALSE_RO(cr_pinning); static unsigned long cr4_pinned_bits __ro_after_init; =20 --=20 2.51.0