Path: ...!2.eu.feeder.erje.net!feeder.erje.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail
From: antispam@fricas.org (Waldek Hebisch)
Newsgroups: comp.arch
Subject: Re: Reverse engineering of Intel branch predictors
Date: Fri, 8 Nov 2024 17:54:45 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vglj93$3mgpb$1@paganini.bofh.team>
References: <vfbfn0$256vo$1@dont-email.me> <vg38o4$1mcfe$1@paganini.bofh.team> <jwvbjytwl4z.fsf-monnier+comp.arch@gnu.org>
Injection-Date: Fri, 8 Nov 2024 17:54:45 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="3883819"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A";
User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
X-Notice: Filtered by postfilter v. 0.9.3
Bytes: 3326
Lines: 51

Stefan Monnier <monnier@iro.umontreal.ca> 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.
> 
>> 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.

It looks extremaly hard if not impossible.

> 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.

Alone that is clearly insufficient.

> 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.

First, one needs to ensure that the CPU performing speculative
fetch will not slown down due to say resource contention.  If you
put some arbitrary limit like one or two speculative fetches in
flight, that is likely to be detectable by the attacker and may
leak information.  If you want several ("arbitrarily many") speculative
fetches without slowing down normal execution, that would mean highly
overprovisioned machine.

> 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.

I am mostly concerned with remote attacks.  To block them it should
be enough to ensure that machine never goes into thermal throttling
(I consider adversary who is not able to directly monitor power
or temperature, so only thing remaining is thermal throttling and
its effect on execution time).

-- 
                              Waldek Hebisch