Re: Another security vulnerability

Scott Lurndal wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

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

It is good, then, that no modern disk I/O is 'effected through
a load'.   It's DMA all the way down, and the inbound DMA transfer
is scheduled by the SATA/NVme/SAS controller.   The timing of the
start of the DMA will vary based on the host controller, the drive
cache
status and drive head scheduler, etc.

I am operating under that model. It still takes OS significant time*
to go from read(file, buffer, length) to the point SR-IOV receives
the command(s) at the drive itself. And then there is the interrupt
routing delay, and ISR + softIRQ delays.
(*) remember we are using a timer that increments at core frequency
essentially counting instructions.

IDE is dead, Jim.

And for a long time.

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

Modern disk drives have significant dram cache on-drive, so you
cannot rely on seek time and rotational latency.

Yes, that is the 3µs number. The OS has to send the I/O to the device, and the device has to send its response back, but there
is no head positioning latency or rotational delay.

                                                 Although if one
knows the drive cache algorithm, it may be possible to game the
transfers such that one can guarantee a miss (and disable any
on-drive speculative reads into the drive cache).