lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <175512395928.1420.9293489818194067558.tip-bot2@tip-bot2>
Date: Wed, 13 Aug 2025 22:25:59 -0000
From: "tip-bot2 for Xin Li (Intel)" <tip-bot2@...utronix.de>
To: linux-tip-commits@...r.kernel.org
Cc: "Xin Li (Intel)" <xin@...or.com>,
 Dave Hansen <dave.hansen@...ux.intel.com>,
 "H. Peter Anvin (Intel)" <hpa@...or.com>,
 Andrew Cooper <andrew.cooper3@...rix.com>, stable@...r.kernel.org,
 x86@...nel.org, linux-kernel@...r.kernel.org
Subject: [tip: x86/entry] x86/fred: Remove ENDBR64 from FRED entry points

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

Commit-ID:     3da01ffe1aeaa0d427ab5235ba735226670a80d9
Gitweb:        https://git.kernel.org/tip/3da01ffe1aeaa0d427ab5235ba735226670a80d9
Author:        Xin Li (Intel) <xin@...or.com>
AuthorDate:    Tue, 15 Jul 2025 23:33:20 -07:00
Committer:     Dave Hansen <dave.hansen@...ux.intel.com>
CommitterDate: Wed, 13 Aug 2025 15:05:32 -07:00

x86/fred: Remove ENDBR64 from FRED entry points

The FRED specification has been changed in v9.0 to state that there
is no need for FRED event handlers to begin with ENDBR64, because
in the presence of supervisor indirect branch tracking, FRED event
delivery does not enter the WAIT_FOR_ENDBRANCH state.

As a result, remove ENDBR64 from FRED entry points.

Then add ANNOTATE_NOENDBR to indicate that FRED entry points will
never be used for indirect calls to suppress an objtool warning.

This change implies that any indirect CALL/JMP to FRED entry points
causes #CP in the presence of supervisor indirect branch tracking.

Credit goes to Jennifer Miller <jmill@....edu> and other contributors
from Arizona State University whose research shows that placing ENDBR
at entry points has negative value thus led to this change.

Note: This is obviously an incompatible change to the FRED
architecture.  But, it's OK because there no FRED systems out in the
wild today. All production hardware and late pre-production hardware
will follow the FRED v9 spec and be compatible with this approach.

[ dhansen: add note to changelog about incompatibility ]

Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code")
Signed-off-by: Xin Li (Intel) <xin@...or.com>
Signed-off-by: Dave Hansen <dave.hansen@...ux.intel.com>
Reviewed-by: H. Peter Anvin (Intel) <hpa@...or.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@...rix.com>
Link: https://lore.kernel.org/linux-hardening/Z60NwR4w%2F28Z7XUa@ubun/
Cc:stable@...r.kernel.org
Link: https://lore.kernel.org/all/20250716063320.1337818-1-xin%40zytor.com
---
 arch/x86/entry/entry_64_fred.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/entry/entry_64_fred.S b/arch/x86/entry/entry_64_fred.S
index 29c5c32..907bd23 100644
--- a/arch/x86/entry/entry_64_fred.S
+++ b/arch/x86/entry/entry_64_fred.S
@@ -16,7 +16,7 @@
 
 .macro FRED_ENTER
 	UNWIND_HINT_END_OF_STACK
-	ENDBR
+	ANNOTATE_NOENDBR
 	PUSH_AND_CLEAR_REGS
 	movq	%rsp, %rdi	/* %rdi -> pt_regs */
 .endm

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ