Sujet : Re: Another security vulnerability
De : mitchalsup (at) *nospam* aol.com (MitchAlsup1)
Groupes : comp.archDate : 11. Jun 2024, 03:11:42
Autres entêtes
Organisation : Rocksolid Light
Message-ID : <0718f44428fe0d519d89e056ac46b016@www.novabbs.org>
References : 1 2 3 4 5 6 7 8 9 10 11
User-Agent : Rocksolid Light
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.
Do SSDs have their own cache ??