https://comsec.ethz.ch/wp-content/files/inception_sec23.pdf

This one affects AMD Zen-Zen4 CPUs (the authors also mention that some
subproblem also affects Intel, but they have not worked out (yet?) how
that can be exploited). Apparently you can train the branch predictor
to predict a branch where there is none. And they use that for
constructing some versatile exploits in conjunction with speculative
execution. I have to read the paper thoroughly to properly understand
it.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Wednesday, August 9, 2023 at 6:24:11 PM UTC+2, Anton Ertl wrote:
> that can be exploited). Apparently you can train the branch predictor
> to predict a branch where there is none. And they use that for

It's just a fairly obvious aliasing in the branch predictor tables -- many addresses alias to the same entry.

Obviously, one can use that to predict branches where there isn't one... the surprise is really that nobody (publicly) did that years ago.

-Peter

Peter Lund wrote:
> On Wednesday, August 9, 2023 at 6:24:11 PM UTC+2, Anton Ertl wrote:
>> that can be exploited). Apparently you can train the branch predictor
>> to predict a branch where there is none. And they use that for
>
> It's just a fairly obvious aliasing in the branch predictor tables -- many addresses alias to the same entry.
>
> Obviously, one can use that to predict branches where there isn't one... the surprise is really that nobody (publicly) did that years ago.

No, the surprise is that a CPU could even care about the branch
predictor withjout actually facing a branch instruction.

(I'm assuming this is what happens?)

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Terje Mathisen <terje.mathisen@tmsw.no> writes:
>Peter Lund wrote:
>> On Wednesday, August 9, 2023 at 6:24:11 PM UTC+2, Anton Ertl wrote:
>>> that can be exploited). Apparently you can train the branch predictor
>>> to predict a branch where there is none. And they use that for
>>
>> It's just a fairly obvious aliasing in the branch predictor tables -- many addresses alias to the same entry.
>>
>> Obviously, one can use that to predict branches where there isn't one... the surprise is really that nobody (publicly) did that years ago.
>
>No, the surprise is that a CPU could even care about the branch
>predictor withjout actually facing a branch instruction.
>
>(I'm assuming this is what happens?)

Perhaps Anton meant that a branch predictor can be
trained[*] to mispredict a conditional branch, causing
microarchitectural state to change as the core
speculatively executes instructions down the wrong
path (which can allow exploitation of microarchitectural
flaws).

[*] By an attacker.

Scott Lurndal wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>> Peter Lund wrote:
>>> On Wednesday, August 9, 2023 at 6:24:11 PM UTC+2, Anton Ertl wrote:
>>>> that can be exploited). Apparently you can train the branch predictor
>>>> to predict a branch where there is none. And they use that for
>>>
>>> It's just a fairly obvious aliasing in the branch predictor tables -- many addresses alias to the same entry.
>>>
>>> Obviously, one can use that to predict branches where there isn't one... the surprise is really that nobody (publicly) did that years ago.
>>
>> No, the surprise is that a CPU could even care about the branch
>> predictor withjout actually facing a branch instruction.
>>
>> (I'm assuming this is what happens?)
>
> Perhaps Anton meant that a branch predictor can be
> trained[*] to mispredict a conditional branch, causing
> microarchitectural state to change as the core
> speculatively executes instructions down the wrong
> path (which can allow exploitation of microarchitectural
> flaws).
>
> [*] By an attacker.

That part has been possible since "forever", and is afaik a key part of
Spectre style attacks. You cannot train on the actual branch inside
OS/secure code, but you can train a bunch of other branches with aliased
addresses?

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Terje Mathisen <terje.mathisen@tmsw.no> writes:
>No, the surprise is that a CPU could even care about the branch
>predictor withjout actually facing a branch instruction.

With CPUs having to predict 2-3 branches per cycle and following one
predicted-taken branch per cycle, while the instruction fetch takes
maybe 4 cycles (if the I-cache and uOp-cache latencies are similar to
similar-sized D-caches), they cannot wait until the instruction fetch
is complete and the possible branch is decoded before acting on the
prediction. I see two ways around this problem:

1) Have a tag in the next-line predictor and don't follow the
predictor if the tag does not match. But what should the CPU do then?

2) Cancel the prediction and everything dependent on it as soon as the
instruction is decoded and turns out not to be a branch. This should
be early enough that the speculative execution has not changed any
microarchitectural state.

Approach 1) appears more practical. If Intel manages to only predict
branches, maybe they have taken it.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Friday, August 11, 2023 at 8:30:05 PM UTC+2, Terje Mathisen wrote:
> Peter Lund wrote:
> > On Wednesday, August 9, 2023 at 6:24:11 PM UTC+2, Anton Ertl wrote:
> >> that can be exploited). Apparently you can train the branch predictor
> >> to predict a branch where there is none. And they use that for
> >
> > It's just a fairly obvious aliasing in the branch predictor tables -- many addresses alias to the same entry.
> >
> > Obviously, one can use that to predict branches where there isn't one.... the surprise is really that nobody (publicly) did that years ago.
> No, the surprise is that a CPU could even care about the branch
> predictor withjout actually facing a branch instruction.

The CPU has to fetch (guided by the branch predictor) long before it knows if there is a branch instruction or not.

-Peter

On Saturday, August 12, 2023 at 1:37:42 AM UTC-5, Anton Ertl wrote:
> Terje Mathisen <terje.m...@tmsw.no> writes:
> >No, the surprise is that a CPU could even care about the branch
> >predictor withjout actually facing a branch instruction.
> With CPUs having to predict 2-3 branches per cycle and following one
> predicted-taken branch per cycle, while the instruction fetch takes
> maybe 4 cycles (if the I-cache and uOp-cache latencies are similar to
> similar-sized D-caches), they cannot wait until the instruction fetch
> is complete and the possible branch is decoded before acting on the
> prediction. I see two ways around this problem:
>
> 1) Have a tag in the next-line predictor and don't follow the
> predictor if the tag does not match. But what should the CPU do then?
>
> 2) Cancel the prediction and everything dependent on it as soon as the
> instruction is decoded and turns out not to be a branch. This should
> be early enough that the speculative execution has not changed any
> microarchitectural state.
<
3) Branch target caching--the predictor selects one of several sets of
instructions at one of the predicted branch targets.
>
> Approach 1) appears more practical. If Intel manages to only predict
> branches, maybe they have taken it.
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>