From mboxrd@z Thu Jan 1 00:00:00 1970 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: 8bit 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.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