Re: Reverse engineering of Intel branch predictors

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