Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Another security vulnerability
Date: Tue, 11 Jun 2024 02:11:42 +0000
Organization: Rocksolid Light
Message-ID: <0718f44428fe0d519d89e056ac46b016@www.novabbs.org>
References: <utpoi2$b6to$1@dont-email.me> <utr63b$u40q$1@dont-email.me> <2024Mar25.093751@mips.complang.tuwien.ac.at> <8biMN.162475$46Te.1680@fx38.iad> <uttc4e$1elji$2@dont-email.me> <ZIAMN.122729$SyNd.55207@fx33.iad> <2024Mar26.173626@mips.complang.tuwien.ac.at> <5811929d48fa825289f362918b74b386@www.novabbs.org> <2024Jun5.103859@mips.complang.tuwien.ac.at> <f9496dc0d3398b24b9ea1912cb060283@www.novabbs.org> <v47v5b$lmqu$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="3818514"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$kZLBN5hC/hzhKXwzg3mCyODe2t5wUg90JLJui16GvAI7zVXWNMema
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 3136
Lines: 51

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 ??