[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bd670c70-47f6-efc7-6ad2-cd833b414ec1@citrix.com>
Date: Sun, 13 Aug 2023 16:23:27 +0100
From: Andrew.Cooper3@...rix.com
To: Peter Zijlstra <peterz@...radead.org>
Cc: Josh Poimboeuf <jpoimboe@...nel.org>, x86@...nel.org,
linux-kernel@...r.kernel.org, David.Kaplan@....com,
gregkh@...uxfoundation.org
Subject: Re: [RFC][PATCH 12/17] x86/cpu: Rename original retbleed return thunk
On 10/08/2023 2:02 pm, Peter Zijlstra wrote:
> On Thu, Aug 10, 2023 at 12:06:17PM +0100, Andrew.Cooper3@...rix.com wrote:
>> On 09/08/2023 3:22 pm, Peter Zijlstra wrote:
>>> On Wed, Aug 09, 2023 at 10:20:31AM -0400, Josh Poimboeuf wrote:
>>>> On Wed, Aug 09, 2023 at 09:12:30AM +0200, Peter Zijlstra wrote:
>>>>> +++ b/tools/objtool/check.c
>>>>> @@ -455,7 +455,12 @@ static int decode_instructions(struct ob
>>>>> return -1;
>>>>> }
>>>>>
>>>>> - if (func->return_thunk || !strcmp(func->name, "srso_safe_ret") || func->alias != func)
>>>>> + /*
>>>>> + * Both zen_return_thunk() and srso_safe_ret() are embedded inside
>>>>> + * another instruction and objtool doesn't grok that. Skip validating them.
>>>>> + */
>>>>> + if (!strcmp(func->name, "zen_return_thunk") ||
>>>>> + !strcmp(func->name, "srso_safe_ret") || func->alias != func)
>>>> Hm, speaking of renaming they should probably be called
>>>> retbleed_return_thunk() and srso_return_thunk().
>>> Yes, clearly naming is better in daylight. Let me regex that.
>> btc_*, not retbleed_*.
>>
>> That way it matches the terminology you'll find in the AMD whitepaper
>> about what's going on, and there's already an entirely different issue
>> called Retbleed.
> So BTC as a whole is the fact that AMD predicts the type of an
> instruction and then picks a predictor to predict the target of that
> instruction, no?
No.
"Branch Type Confusion" is the technical name AMD gave last year's
issue. Hence the name of the whitepaper about it,
https://www.amd.com/system/files/documents/technical-guidance-for-mitigating-branch-type-confusion.pdf
Each of these issues has been given a technical name given by one of the
vendors. Spectre-v1 was Bounds Check Bypass, Spectre-v2 was Branch
Target Injection, etc. We can debate at some other point whether the
names are ideal or not, but the point is that these are the names that
cross-reference with the vendor documentation.
The naming scheme either needs to be BTC+SRSO (AMD's names), *or*
Retbleed+Inception (EthZ's names, remembering that Retbleed is still
ambiguous), but not a mix of the two.
~Andrew
Powered by blists - more mailing lists