[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230814120656.GG776869@hirez.programming.kicks-ass.net>
Date: Mon, 14 Aug 2023 14:06:56 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Andrew.Cooper3@...rix.com
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 Mon, Aug 14, 2023 at 12:31:04PM +0100, Andrew.Cooper3@...rix.com wrote:
> 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.
This early stall avoids the actual type confusion from escaping
(mostly).
> And yes - this is why SRSO is not an extension of BTC. The
> micro-architectural details are very different.
Yeah, it is more related to intel-retbleed, both exhaust the return
stack... /me runs :-)
Powered by blists - more mailing lists