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 : 10. Jun 2024, 23:06:01
Autres entêtes
Organisation : Rocksolid Light
Message-ID : <f9496dc0d3398b24b9ea1912cb060283@www.novabbs.org>
References : 1 2 3 4 5 6 7 8 9
User-Agent : Rocksolid Light
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

Date Sujet#  Auteur
24 Mar 24 * Another security vulnerability58Stephen Fuld
24 Mar 24 +* Re: Another security vulnerability4MitchAlsup1
25 Mar 24 i+* Re: Another security vulnerability2Stefan Monnier
26 Mar 24 ii`- Re: Another security vulnerability1Michael S
26 Mar 24 i`- Re: Another security vulnerability1Michael S
24 Mar 24 +* Re: Another security vulnerability10Lawrence D'Oliveiro
25 Mar 24 i+- Re: Another security vulnerability1Stefan Monnier
25 Mar 24 i`* Re: Another security vulnerability8Stephen Fuld
25 Mar 24 i `* Re: Another security vulnerability7Lawrence D'Oliveiro
26 Mar 24 i  +* Re: Another security vulnerability5MitchAlsup1
26 Mar 24 i  i`* Re: Another security vulnerability4Lawrence D'Oliveiro
27 Mar 24 i  i `* Re: Another security vulnerability3Stephen Fuld
28 Mar 24 i  i  `* Re: Another security vulnerability2Lawrence D'Oliveiro
28 Mar 24 i  i   `- Re: Another security vulnerability1MitchAlsup1
26 Mar 24 i  `- Re: Another security vulnerability1Michael S
25 Mar 24 +* Re: Another security vulnerability18Thomas Koenig
25 Mar 24 i+* Re: Another security vulnerability16Anton Ertl
26 Mar 24 ii+* Re: Another security vulnerability13Lawrence D'Oliveiro
26 Mar 24 iii`* Re: Another security vulnerability12Anton Ertl
5 Jun 24 iii `* Re: Another security vulnerability11MitchAlsup1
5 Jun 24 iii  +* Re: Another security vulnerability9Anton Ertl
11 Jun 24 iii  i`* Re: Another security vulnerability8MitchAlsup1
11 Jun 24 iii  i +* Re: Another security vulnerability6Stephen Fuld
11 Jun 24 iii  i i`* Re: Another security vulnerability5MitchAlsup1
11 Jun 24 iii  i i `* Re: Another security vulnerability4Stephen Fuld
11 Jun 24 iii  i i  `* Re: Another security vulnerability3Terje Mathisen
11 Jun 24 iii  i i   `* SSDs (was: Another security vulnerability)2Stefan Monnier
11 Jun 24 iii  i i    `- Re: SSDs1Chris M. Thomasson
11 Jun 24 iii  i `- Re: Another security vulnerability1MitchAlsup1
11 Jun 24 iii  `- Re: Another security vulnerability1MitchAlsup1
26 Mar 24 ii`* Re: Another security vulnerability2Anton Ertl
26 Mar 24 ii `- Re: Another security vulnerability1Anton Ertl
25 Mar 24 i`- Re: Another security vulnerability1Michael S
25 Mar 24 +* Re: Another security vulnerability22Anton Ertl
26 Mar 24 i`* Re: Another security vulnerability21Michael S
27 Mar 24 i `* Re: Another security vulnerability20Thomas Koenig
27 Mar 24 i  +* Re: Another security vulnerability2Thomas Koenig
27 Mar 24 i  i`- Re: Another security vulnerability1Thomas Koenig
27 Mar 24 i  +- Re: Another security vulnerability1Anton Ertl
27 Mar 24 i  `* Re: Another security vulnerability16Anton Ertl
27 Mar 24 i   `* Re: Another security vulnerability15MitchAlsup1
28 Mar 24 i    +* Re: Another security vulnerability4MitchAlsup1
29 Mar 24 i    i`* Re: Another security vulnerability3Paul A. Clayton
29 Mar 24 i    i `* Re: Another security vulnerability2Paul A. Clayton
30 Mar 24 i    i  `- Re: Another security vulnerability1MitchAlsup1
3 Apr 24 i    `* Re: Another security vulnerability10Stefan Monnier
3 Apr 24 i     `* Re: Another security vulnerability9Thomas Koenig
3 Apr 24 i      +* Re: Another security vulnerability6MitchAlsup1
4 Apr 24 i      i`* Re: Another security vulnerability5Thomas Koenig
4 Apr 24 i      i `* Re: Another security vulnerability4MitchAlsup1
4 Apr 24 i      i  +- Re: Another security vulnerability1MitchAlsup1
7 Apr 24 i      i  `* Re: Another security vulnerability2Paul A. Clayton
8 Apr 24 i      i   `- Re: Another security vulnerability1MitchAlsup1
5 Apr 24 i      `* Re: Another security vulnerability2Stefan Monnier
5 Apr 24 i       `- Re: Another security vulnerability1MitchAlsup1
25 Mar 24 `* Re: Another security vulnerability3John Savard
25 Mar 24  `* Re: Another security vulnerability2Michael S
26 Mar 24   `- Re: Another security vulnerability1Lawrence D'Oliveiro

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal