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: <2024Mar25.093751@mips.complang.tuwien.ac.at> <8biMN.162475$46Te.1680@fx38.iad> <2024Mar26.173626@mips.complang.tuwien.ac.at> <5811929d48fa825289f362918b74b386@www.novabbs.org> <2024Jun5.103859@mips.complang.tuwien.ac.at> 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 ??