I saw this and can't figure out how significant it is. Is it a real
problem, and if so, is this a good solution?

https://eprint.iacr.org/2022/1228.pdf

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Wednesday, August 2, 2023 at 3:52:46 PM UTC-5, Stephen Fuld wrote:
> I saw this and can't figure out how significant it is. Is it a real
> problem, and if so, is this a good solution?
>
> https://eprint.iacr.org/2022/1228.pdf
>
Maybe::
Cost:: 1 cycle of added cache latency (300ps in 15nm) for a 3GHz CPU
...........maybe 2 cycles on 5GHz machines
Gain:: No Spectré-like attacks.
Alternative:
Seznik:: randomize associativity (mid 1990s)
Cost:: 1 gate of delay
Gain:: dramatic alteration in the "noise floor" of cache access patterns.
Alternative::
Don't update cache structures until causing instruction retires
Cost:: more use of Miss Buffers
Gain:: Insensitive to Spectré-like attacks.
With no loss in performance.
<
I think the cost of adding 1 cycle in the LD path is the harmful part.
{{Just about everything else can be "piped away"}}
>
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

On 8/2/2023 4:12 PM, MitchAlsup wrote:
> On Wednesday, August 2, 2023 at 3:52:46 PM UTC-5, Stephen Fuld wrote:
>> I saw this and can't figure out how significant it is. Is it a real
>> problem, and if so, is this a good solution?
>>
>> https://eprint.iacr.org/2022/1228.pdf
>>
> Maybe::
> Cost:: 1 cycle of added cache latency (300ps in 15nm) for a 3GHz CPU
> ..........maybe 2 cycles on 5GHz machines
> Gain:: No Spectré-like attacks.
> Alternative:
> Seznik:: randomize associativity (mid 1990s)
> Cost:: 1 gate of delay
> Gain:: dramatic alteration in the "noise floor" of cache access patterns.
> Alternative::
> Don't update cache structures until causing instruction retires
> Cost:: more use of Miss Buffers
> Gain:: Insensitive to Spectré-like attacks.
> With no loss in performance.
> <
> I think the cost of adding 1 cycle in the LD path is the harmful part.
> {{Just about everything else can be "piped away"}}

I may very well be wrong about this, but while I think you are right
about Spectre, I think this is targeting something else, specifically
measuring the load instruction latency to determine if a data item is in
cache, then using that for multiple addresses to try to get access
patterns. It isn't about speculative execution, so your solution
wouldn't help.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>I saw this and can't figure out how significant it is. Is it a real
>problem, and if so, is this a good solution?
>
>https://eprint.iacr.org/2022/1228.pdf

I have read only the abstract, but here's my take:

Cache side channels are a real problem, but for architectural
execution and for speculative exection (Spectre).

For architectural execution, the existing solution is to write the
code in a way that the cache accesses are secret-independent; this is
so burdensome that it is done only for key-handling cryptographic
code, i.e., for the dearest secrets. I expect that crypto code will
continue to use this technique (because it always works), so it won't
profit from randomized caches. Other code can benefit from randomized
caches, to some extent (see below).

For speculative execution, the existing mitigation is to write *all*
code with techniques that prevent either speculative execution (such
as retpolines at a huge execution time cost) or prevent speculative
access to arbitrary memory; this is doable at some cost for
bounds-checked languages, but very expensive in programmer time and
also costly in run-time for languages like C, so it is usually not
done for C (and, I guess, C++) programs. Again, the vulnerable code
can benefit from randomized caches to some extent.

"To some extent"? Code in the same address space will see the cache
in the same way as the secret-handling code, so the randomized cache
won't protect against attacks that go through such code (as many
Spectre attacks do).

So randomized caches are only a partial solution, and we should better
use a real fix for Spectre. For architectural execution, we will
continue to use secret-independent memory accesses for crypto code,
but it can provide some security improvement for other code. Whether
that is worth the cost, is the question.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On 8/3/2023 1:02 AM, Anton Ertl wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>> I saw this and can't figure out how significant it is. Is it a real
>> problem, and if so, is this a good solution?
>>
>> https://eprint.iacr.org/2022/1228.pdf
>
> I have read only the abstract, but here's my take:
>
> Cache side channels are a real problem, but for architectural
> execution and for speculative exection (Spectre).
>
> For architectural execution, the existing solution is to write the
> code in a way that the cache accesses are secret-independent; this is
> so burdensome that it is done only for key-handling cryptographic
> code, i.e., for the dearest secrets. I expect that crypto code will
> continue to use this technique (because it always works), so it won't
> profit from randomized caches. Other code can benefit from randomized
> caches, to some extent (see below).
>
> For speculative execution, the existing mitigation is to write *all*
> code with techniques that prevent either speculative execution (such
> as retpolines at a huge execution time cost) or prevent speculative
> access to arbitrary memory; this is doable at some cost for
> bounds-checked languages, but very expensive in programmer time and
> also costly in run-time for languages like C, so it is usually not
> done for C (and, I guess, C++) programs. Again, the vulnerable code
> can benefit from randomized caches to some extent.
>
> "To some extent"? Code in the same address space will see the cache
> in the same way as the secret-handling code, so the randomized cache
> won't protect against attacks that go through such code (as many
> Spectre attacks do).
>
> So randomized caches are only a partial solution, and we should better
> use a real fix for Spectre. For architectural execution, we will
> continue to use secret-independent memory accesses for crypto code,
> but it can provide some security improvement for other code. Whether
> that is worth the cost, is the question.

Thanks Anton. I think you present a good summary of the situation.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)