Re: Another security vulnerability

mitchalsup@aol.com (MitchAlsup1) writes:

I am resurrecting this thread to talk about a different cache that
may or may not be vulnerable to Spectré like attacks.
>
Consider an attack strategy that measures whether a disk sector/block
is in (or not in) the OS disk cache. {Very similar to attacks that
figure out if a cache line is in the Data Cache (or not).}
>
Any ideas ??

If you want to claim that there is a vulnerability, it's your job to
demonstrate it.

That being said, filling the OS disk cache requires I/O commands,
typically effected through stores that make it to the I/O device.  In
cases where the I/O is effected through a load, the I/O device is in
an uncacheable part of the address space (otherwise even
non-speculative accesses would not work correctly, and speculative
accesses would have caused havoc long ago), and the load is delayed
until it is no longer speculative.

Ok, you might say, what about just the preparation of the buffer in
ordinary write-back-cached memory?  Yes, that can happen
speculatively, so speculatively executed code might somehow see a
buffer that should later be used for some I/O.  But where is the
security vulnerability in this scenario?  Once the speculation turns
out to be wrong, all the changes in the store buffer will be canceled.
The only trace that remains will (on Spectre-vulnerable hardware) be
in the caches and other microarchitectural features, just as with
existing Spectre attacks.  There is nothing special about disk buffers
here.

And on Spectre-invulnerable hardware (which still does not exist 7
years after the vulnerability has been reported to Intel and AMD:-(,
and the recent announcements of Zen5, Lunar Lake and the new ARM cores
are not promising) no trace of the speculation will be left in
microarchitectural state when it turns out to be wrong.

BTW, it's Spectre without accent, see <https://spectreattack.com/>

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