Deutsch English Français Italiano |
<o32f6jlq2qpi9s1u8giq521vv40uqrkiod@4ax.com> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: John Savard <quadibloc@servername.invalid> Newsgroups: comp.arch Subject: Re: Privilege Levels Below User Date: Mon, 10 Jun 2024 17:22:05 -0600 Organization: A noiseless patient Spider Lines: 45 Message-ID: <o32f6jlq2qpi9s1u8giq521vv40uqrkiod@4ax.com> References: <jai66jd4ih4ejmek0abnl4gvg5td4obsqg@4ax.com> <h0ib6j576v8o37qu1ojrsmeb5o88f29upe@4ax.com> <2024Jun9.185245@mips.complang.tuwien.ac.at> <38ob6jl9sl3ceb0qugaf26cbv8lk7hmdil@4ax.com> <2024Jun10.091648@mips.complang.tuwien.ac.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Date: Tue, 11 Jun 2024 01:22:07 +0200 (CEST) Injection-Info: dont-email.me; posting-host="f752231138247ec5b6f53ce61cda1d0c"; logging-data="727486"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Db9ol6stjLNN0Fav6pdI+CRTWFr8WqEA=" Cancel-Lock: sha1:ga+nzTy15XDf0xsPzTaduppxowI= X-Newsreader: Forte Free Agent 3.3/32.846 Bytes: 3127 On Mon, 10 Jun 2024 07:16:48 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >John Savard <quadibloc@servername.invalid> writes: >>In the case of Spectre, fixing the hardware has a cost in performance. > >How do you know? > >Papers on so-called "invisible speculation" schemes have reported >slowdowns <10% for the more advanced schemes, with IIRC some even >reporting a speedup. I've heard claims - especially from Mitch Alsup - that, indeed, all one has to do is avoid certain _mistakes_ when designing a pipeline, and there's no room for Spectre any more. I'm no expert on these things at all, so I don't know that this can't be true. But I also don't know that it _is_ true. What does Spectre exploit? it exploits the fact that speculative execution keeps around data that was fetched into cache by the speculative execution of some code that was never supposed to be executed. Just in case it might be useful later. Obviously, keeping around any data that just happens to be accidentally in cache, just in case it might be useful later, does have a positive (but likely very slight) effect on performance. Being strict about what speculative execution can do, on the other hand, so nothing is allowed to leak information, will reduce performance... at least a little bit. It could well be that the losses aren't enough to be concerned about, if this is done carefully. That is, not even the 3% quoted as the cost of one of the earliest fixes. But since I've heard higher figures for the fixes for later variants, without positive knowledge, I have to be skeptical about claims that all possible variants of this kind of attack can be prevented at little cost. And Rowhammer is even worse. It's not at all clear to me what can be done without adding an expensive layer of monitoring to memory accesses. However, only DRAM is vulnerable to Rowhammer, and so it may be possible to turn cache into a bulwark against it somehow. John Savard