Sujet : Re: Reverse engineering of Intel branch predictors
De : antispam (at) *nospam* fricas.org (Waldek Hebisch)
Groupes : comp.archDate : 01. Nov 2024, 20:04:38
Autres entêtes
Organisation : To protect and to server
Message-ID : <vg38o4$1mcfe$1@paganini.bofh.team>
References : 1
User-Agent : tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
Thomas Koenig <
tkoenig@netcologne.de> wrote:
Seems like Intel branch predictors have been pretty completely
reverse-engineered. The following paper promises to for very
interesting reading:
https://www.usenix.org/conference/usenixsecurity24/presentation/li-luyi
I wonder what you think of this...
There are more papers on this topic. There were several papers
on variations of Spectre. I think that there is simple condition
which guarantees that nothing Spectre-related affects given
processor: the sequence of microarchitecutral operations (incuding
speculative operations) should depend only on architecturaly
executed instructions. So, processor may do widely speculative
things, but only base speculation on architecturaly executed
instructions. Some people try to just close single hole at
a time, IMO it is hopeless, there are too many possible
variations. And weaker conditions, like "cancelling" effects
of speculative instructions are likely to fail.
My impression is that it is relatively easy to modify Intel
scheme to depend only on architectural state. Impact of such
restriction on performance is not clear. In case of branch
predictor itself it means delay feedback by some number of clocks,
which looks like minor cost. OTOH delaying fetches from
speculatively fetched addresses will increase latency on
critical path, possibly leading to significant slowdown.
-- Waldek Hebisch