Re: Reverse engineering of Intel branch predictors

In case of branch predictor itself it means delay feedback by some
number of clocks, which looks like minor cost.

You can still make your next predictions based on "architectural state
+ pending predictions" if the pending predictions themselves only
depend ultimately on the architectural state.

OTOH delaying fetches from speculatively fetched addresses will
increase latency on critical path, possibly leading to
significant slowdown.

I think you can similarly perform eagerly the fetches from speculatively
fetched addresses but only if you can ensure that these will leave no
trace if the speculation happens to fail.

So whether and how you can do it depends the definition of "leave no
trace".  E.g. Mitch argues you can do it if you can refrain from putting
that info into the normal cache (where it would have to displace
something else, thus leaving a trace) and instead have to keep it in
what we could call a "speculative cache" but would likely be just some
sort of load buffer.

If "leave no trace" includes not slowing down other concurrent memory
accesses (e.g. from other CPUs), it might require some kind of
priority scheme.

If you're worried about, say, a Spectre-like attack measuring the
temperature or the power consumption of the CPU to try and guess what
operations were performed (or what addresses were accessed, ...)
speculatively, then you'd have to be yet more careful.

If you're worried about an attacker that can witnessing the actual
accesses to the DRAM, ...


        Stefan