Re: Another security vulnerability

Liste des GroupesRevenir à c arch 
Sujet : Re: Another security vulnerability
De : mitchalsup (at) *nospam* aol.com (MitchAlsup1)
Groupes : comp.arch
Date : 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 ??

Date Sujet#  Auteur
4 Jun 24 * Re: Another security vulnerability11MitchAlsup1
5 Jun 24 +* Re: Another security vulnerability9Anton Ertl
10 Jun 24 i`* Re: Another security vulnerability8MitchAlsup1
10 Jun 24 i +* Re: Another security vulnerability6Stephen Fuld
11 Jun 24 i i`* Re: Another security vulnerability5MitchAlsup1
11 Jun 24 i i `* Re: Another security vulnerability4Stephen Fuld
11 Jun 24 i i  `* Re: Another security vulnerability3Terje Mathisen
11 Jun 24 i i   `* SSDs (was: Another security vulnerability)2Stefan Monnier
11 Jun 24 i i    `- Re: SSDs1Chris M. Thomasson
11 Jun 24 i `- Re: Another security vulnerability1MitchAlsup1
10 Jun 24 `- Re: Another security vulnerability1MitchAlsup1

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal