Re: Another security vulnerability

Anton Ertl wrote:

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.

It seems to me that there are 4 service intervals:
a) in application buffering--this suffers no supervisor call latency
b) hit in the disk cache--this suffers no I/O latency
c) hit in the SATA drive cache--this suffers only I/O latency
d) Drive positions head and waits for the sector to arrive
I believe that the service intervals are fairly disjoint so there can
be identified with a high precision timer. My guesses::
a) 50ns
b) 300ns
c) 3µs
d) 10ms
{{I remember that just pushing I/O commands out PCIe takes µs amounts of time, while head and rotational delays of disks are ms.}}

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.

Spectré works by filling its data cache with data it controls, and then
measuring which cache lines got displaced by other activities; and then
inferring the data in those lines.
What I am proposing here is that the attacker fills the disk cache with
his file data, then measuring what parts of the disk cache got
overwritten.
That mush is straightforward. The problem is in trying to infer the bit
patterns of that overwriting data.
Spectré makes 2 back to back accesses and sensitizes the various caches
and predictors by doing completely legal code and then using the came code to access something that should not be accessible--that is the microarchitectural opening in the security. With LD latency increasing
from 2 cycles (MIPS) to 5 cycles (latest Intel) the desire to process
back to back dependent loads, means the second LD starts when the data
is accessed, but all of the checks that (PPN = PTE.PPN & access checks)
have not been completed. This second address is presented to the cache
for an access and will be cancelled later, but if it takes a miss, the
miss buffer will service the miss and install (alter data) in the cache
displacing data that should have remained in the cache. By determining
Which cache lines got displaces infers the data accessed that should not have been.
So the question is how to setup data in the disk cache such that that
kind of inference can be made.

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