* [PATCH v3 1/1] x86/fred: Remove ENDBR64 from FRED entry points
@ 2025-07-16 6:33 Xin Li (Intel)
2025-08-11 22:48 ` Xin Li
2025-08-13 21:07 ` Dave Hansen
0 siblings, 2 replies; 4+ messages in thread
From: Xin Li (Intel) @ 2025-07-16 6:33 UTC (permalink / raw)
To: linux-kernel
Cc: luto, tglx, mingo, bp, dave.hansen, x86, hpa, jmill, peterz,
andrew.cooper3, stable
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@asu.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.
Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code")
Link: https://lore.kernel.org/linux-hardening/Z60NwR4w%2F28Z7XUa@ubun/
Reviewed-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Xin Li (Intel) <xin@zytor.com>
Cc: Jennifer Miller <jmill@asu.edu>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: stable@vger.kernel.org # v6.9+
---
Change in v3:
*) Revise the FRED spec change description to clearly indicate that it
deviates from previous versions and is based on new research showing
that placing ENDBR at entry points has negative value (Andrew Cooper).
Change in v2:
*) CC stable and add a fixes tag (PeterZ).
---
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 29c5c32c16c3..907bd233c6c1 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
--
2.50.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH v3 1/1] x86/fred: Remove ENDBR64 from FRED entry points
2025-07-16 6:33 [PATCH v3 1/1] x86/fred: Remove ENDBR64 from FRED entry points Xin Li (Intel)
@ 2025-08-11 22:48 ` Xin Li
2025-08-13 21:07 ` Dave Hansen
1 sibling, 0 replies; 4+ messages in thread
From: Xin Li @ 2025-08-11 22:48 UTC (permalink / raw)
To: linux-kernel
Cc: luto, tglx, mingo, bp, dave.hansen, x86, hpa, jmill, peterz,
andrew.cooper3, stable
On 7/15/2025 11:33 PM, Xin Li (Intel) wrote:
> 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@asu.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.
>
> Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code")
> Link: https://lore.kernel.org/linux-hardening/Z60NwR4w%2F28Z7XUa@ubun/
> Reviewed-by: H. Peter Anvin (Intel) <hpa@zytor.com>
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Xin Li (Intel) <xin@zytor.com>
> Cc: Jennifer Miller <jmill@asu.edu>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: stable@vger.kernel.org # v6.9+
> ---
>
> Change in v3:
> *) Revise the FRED spec change description to clearly indicate that it
> deviates from previous versions and is based on new research showing
> that placing ENDBR at entry points has negative value (Andrew Cooper).
>
> Change in v2:
> *) CC stable and add a fixes tag (PeterZ).
> ---
> 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 29c5c32c16c3..907bd233c6c1 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
Ping :)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v3 1/1] x86/fred: Remove ENDBR64 from FRED entry points
2025-07-16 6:33 [PATCH v3 1/1] x86/fred: Remove ENDBR64 from FRED entry points Xin Li (Intel)
2025-08-11 22:48 ` Xin Li
@ 2025-08-13 21:07 ` Dave Hansen
2025-08-13 21:57 ` H. Peter Anvin
1 sibling, 1 reply; 4+ messages in thread
From: Dave Hansen @ 2025-08-13 21:07 UTC (permalink / raw)
To: Xin Li (Intel), linux-kernel
Cc: luto, tglx, mingo, bp, dave.hansen, x86, hpa, jmill, peterz,
andrew.cooper3, stable
On 7/15/25 23:33, Xin Li (Intel) wrote:
> 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.
So, the spec is being updated or has been updated to reflect the new
architecture, right?
Remind me, are there no FRED systems out in the wild today, so we don't
have to worry about breaking anything?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v3 1/1] x86/fred: Remove ENDBR64 from FRED entry points
2025-08-13 21:07 ` Dave Hansen
@ 2025-08-13 21:57 ` H. Peter Anvin
0 siblings, 0 replies; 4+ messages in thread
From: H. Peter Anvin @ 2025-08-13 21:57 UTC (permalink / raw)
To: Dave Hansen, Xin Li (Intel), linux-kernel
Cc: luto, tglx, mingo, bp, dave.hansen, x86, jmill, peterz,
andrew.cooper3, stable
On 2025-08-13 14:07, Dave Hansen wrote:
> On 7/15/25 23:33, Xin Li (Intel) wrote:
>> 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.
>
> So, the spec is being updated or has been updated to reflect the new
> architecture, right?
>
> Remind me, are there no FRED systems out in the wild today, so we don't
> have to worry about breaking anything?
Correct. The FRED v9 spec contains this change.
All production hardware and late pre-production hardware will have this.
-hpa
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-08-13 21:59 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-07-16 6:33 [PATCH v3 1/1] x86/fred: Remove ENDBR64 from FRED entry points Xin Li (Intel)
2025-08-11 22:48 ` Xin Li
2025-08-13 21:07 ` Dave Hansen
2025-08-13 21:57 ` H. Peter Anvin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).