[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <025501f2-5122-44c2-ae20-0cce86e8c426@zytor.com>
Date: Tue, 15 Jul 2025 08:34:51 -0700
From: Xin Li <xin@...or.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org, luto@...nel.org, tglx@...utronix.de,
mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com,
x86@...nel.org, hpa@...or.com, jmill@....edu,
andrew.cooper3@...rix.com
Subject: Re: [PATCH v1 1/1] x86/fred: Remove ENDBR64 from FRED entry points
On 7/15/2025 1:40 AM, Peter Zijlstra wrote:
> On Mon, Jul 14, 2025 at 11:50:57PM -0700, Xin Li wrote:
>> On 7/14/2025 11:44 PM, Xin Li (Intel) wrote:
>>> The FRED specification v9.0 states 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 work led to this change.
>>>
>>> Link:https://lore.kernel.org/linux-hardening/Z60NwR4w%2F28Z7XUa@ubun/
>>> Reviewed-by: H. Peter Anvin (Intel)<hpa@...or.com>
>>> Signed-off-by: Xin Li (Intel)<xin@...or.com>
>>> Cc: Jennifer Miller<jmill@....edu>
>>> Cc: Peter Zijlstra<peterz@...radead.org>
>>> Cc: Andrew Cooper<andrew.cooper3@...rix.com>
>>> Cc: H. Peter Anvin<hpa@...or.com>
>> Sorry, forgot to put CC stable.
> Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code")
>
> Right?
You bet!
Will send v2 to address it soon.
Powered by blists - more mailing lists