Re: Another security vulnerability

MitchAlsup1 wrote:

Stephen Fuld wrote:
 

MitchAlsup1 wrote:

 

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

 
 

That's all true except if the "disk" is actually an SSD.

 
 
 

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

 

An SSD reduces d significantly.  Probably still disjoint, but not
nearly as much.

 
An SSD should reduce d to c.

Not quite.  There is still a controller withuin the SSD that executes
some code to perform its functionality (e.g. mapping, wear leveling,
bad block bypassing, etdc).  So d will be greater than c, but not by as
much as it would be if it were a spinning disk,

 
Do SSDs have their own cache ??

Usually, yes.



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