Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Stefan Monnier <monnier@iro.umontreal.ca>
Newsgroups: comp.arch
Subject: Re: Reverse engineering of Intel branch predictors
Date: Mon, 11 Nov 2024 15:55:01 -0500
Organization: A noiseless patient Spider
Lines: 42
Message-ID: <jwv7c99sdzw.fsf-monnier+comp.arch@gnu.org>
References: <vfbfn0$256vo$1@dont-email.me> <vg38o4$1mcfe$1@paganini.bofh.team>
	<jwvbjytwl4z.fsf-monnier+comp.arch@gnu.org>
	<vglj93$3mgpb$1@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Mon, 11 Nov 2024 21:55:07 +0100 (CET)
Injection-Info: dont-email.me; posting-host="3b98026d4d04c50d28c1d363b2681b28";
	logging-data="1236548"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19CxUt/7Tp0Yb5IYHmf/mlf7h/HZYu4Pf0="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:QxQszecBiLPKoKv6RtCStHh9bM4=
	sha1:OI/+GqNQNtBPAHcyje4ABvKlsBE=
Bytes: 3076

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

AFAIK there have been attempts at using resource contention as a side
channel, indeed, but the effectiveness depends on the scale of the impact
of resource contention compared to the "ambient noise".

IOW, there we get into the realm of quantifying the leaks.

But AFAIK if you limit yourself to L1 accesses I believe it's not too
hard to avoid all resource contentions (i.e. make sure that
no speculative access can slow down a less speculative access).

> If you want several ("arbitrarily many") speculative fetches without
> slowing down normal execution, that would mean highly
> overprovisioned machine.

Once you're into the higher levels of cache, I don't have a clear
picture of how hard/easy it would be to maintain the "no
trace" guarantee.  And the higher in the hierarchy you go, the more
visible any slowdown will be, I expect.

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

Thermal and power information is usually made available to non-root
processes, so I think we should assume remote attackers have access
to it.  Maybe the granularity is coarse enough to make the leak
impractical (but we're again in the realm of quantifying leaks, here).


        Stefan