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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 14 Aug 2023 12:31:04 +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 14/08/2023 11:34 am, Peter Zijlstra wrote:
> On Sun, Aug 13, 2023 at 04:23:27PM +0100, Andrew.Cooper3@...rix.com wrote:
>> On 10/08/2023 2:02 pm, Peter Zijlstra wrote:
>>> 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
> Bah, then what do we call the actual underlying issue that the AMD
> branch predictor starts by predicting the next instruction type --
> before it has been decoded -- meaning it can predict it wrong, which
> then leads to a tons of other issues, including but not limited to:
>
>  SLS through JMP (or pretty much anything else)
>  RET from BTB
>
> ?
>
> Calling *THAT* branch-type-confusion makes a heap more sense to me.

You know the branch predictor being ahead of decode is a property that
exists in both vendors CPUs and has done for more than a decade
already?  Bad branch type predictions are relevant for a number of the
Intel issues too - they just don't talk as openly about it.

The thing that missing from AMD Zen2-and-older CPUs is the early stall
in decode when the branch type prediction is discovered to be wrong. 
Intel have this early feeback cycle, as do AMD Zen3 and later.

And yes - this is why SRSO is not an extension of BTC.  The
micro-architectural details are very different.

~Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ