Re: Reverse engineering of Intel branch predictors

Liste des GroupesRevenir à c arch 
Sujet : Re: Reverse engineering of Intel branch predictors
De : mitchalsup (at) *nospam* aol.com (MitchAlsup1)
Groupes : comp.arch
Date : 05. Nov 2024, 21:17:46
Autres entêtes
Organisation : Rocksolid Light
Message-ID : <093a59a6a30cf5daa17bd9d85f94de5b@www.novabbs.org>
References : 1 2 3
User-Agent : Rocksolid Light
On Tue, 5 Nov 2024 19:26:28 +0000, Stefan Monnier wrote:

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.
Key word:: Ultimately !

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.
This is also how one recovers an out-of-memory-order speculative
memref--you quit the OoO request and replay it from AGEN. This
allows for relaxed memory order performance while achieving
stronger memory order when OoO, that could cause order-harm,
is detected.

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.
Leave no trace, AND have a plan to recover should an non µArchitectural
event become visible.

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.
Once you include the "plan to recover" you can loosen up the
operational memory order rules and tighten them upon discovery
of order violations.

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, ...
This brings to mind something we found in the Mc 88120 project.
We could take a checkpoint (write to disk) and restore later--
but we found we had to also recover the electrical state of the DRAM
Bus and to RAS the proper banks to get the "same timing" on later
runs on that checkpoint.

>
        Stefan

Date Sujet#  Auteur
23 Oct 24 * Reverse engineering of Intel branch predictors34Thomas Koenig
23 Oct 24 +* Re: Reverse engineering of Intel branch predictors24MitchAlsup1
28 Oct 24 i`* Re: Reverse engineering of Intel branch predictors23Stefan Monnier
5 Nov 24 i `* Re: Reverse engineering of Intel branch predictors22MitchAlsup1
11 Nov 24 i  +* Re: Reverse engineering of Intel branch predictors2Thomas Koenig
11 Nov 24 i  i`- Re: Reverse engineering of Intel branch predictors1MitchAlsup1
11 Nov 24 i  `* Re: Reverse engineering of Intel branch predictors19Stefan Monnier
11 Nov 24 i   `* Re: Reverse engineering of Intel branch predictors18MitchAlsup1
12 Nov 24 i    `* Re: Reverse engineering of Intel branch predictors17Stefan Monnier
12 Nov 24 i     `* Re: Reverse engineering of Intel branch predictors16MitchAlsup1
12 Nov 24 i      +* Re: Reverse engineering of Intel branch predictors13Stefan Monnier
12 Nov 24 i      i`* Re: Reverse engineering of Intel branch predictors12MitchAlsup1
13 Nov 24 i      i +* Re: Reverse engineering of Intel branch predictors7Stefan Monnier
13 Nov 24 i      i i`* Re: Reverse engineering of Intel branch predictors6Terje Mathisen
13 Nov 24 i      i i `* Re: Reverse engineering of Intel branch predictors5Stefan Monnier
13 Nov 24 i      i i  `* Re: Reverse engineering of Intel branch predictors4Thomas Koenig
13 Nov 24 i      i i   +* Re: Reverse engineering of Intel branch predictors2Stefan Monnier
14 Nov 24 i      i i   i`- Re: Reverse engineering of Intel branch predictors1Thomas Koenig
14 Nov 24 i      i i   `- Interpreters and indirect-branch prediction (was: Reverse ...)1Anton Ertl
13 Nov 24 i      i `* Interpreters and indirect-branch prediction4Anton Ertl
13 Nov 24 i      i  `* Re: Interpreters and indirect-branch prediction3MitchAlsup1
13 Nov 24 i      i   `* Re: Interpreters and indirect-branch prediction2BGB
14 Nov 24 i      i    `- Re: Interpreters and indirect-branch prediction1BGB
13 Nov 24 i      `* Re: Reverse engineering of Intel branch predictors2Brett
13 Nov 24 i       `- Re: Reverse engineering of Intel branch predictors1MitchAlsup1
1 Nov 24 `* Re: Reverse engineering of Intel branch predictors9Waldek Hebisch
1 Nov 24  +- Re: Reverse engineering of Intel branch predictors1MitchAlsup1
5 Nov 24  `* Re: Reverse engineering of Intel branch predictors7Stefan Monnier
5 Nov 24   +- Re: Reverse engineering of Intel branch predictors1MitchAlsup1
8 Nov 24   `* Re: Reverse engineering of Intel branch predictors5Waldek Hebisch
8 Nov 24    +* Re: Reverse engineering of Intel branch predictors3MitchAlsup1
10 Nov 24    i`* Re: Reverse engineering of Intel branch predictors2Waldek Hebisch
10 Nov 24    i `- Re: Reverse engineering of Intel branch predictors1MitchAlsup1
11 Nov 24    `- Re: Reverse engineering of Intel branch predictors1Stefan Monnier

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal