Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Privilege Levels Below User
Date: Tue, 11 Jun 2024 00:27:02 +0000
Organization: Rocksolid Light
Message-ID: <3a691dbdc80ebcc98d69c3a234f4135b@www.novabbs.org>
References: <jai66jd4ih4ejmek0abnl4gvg5td4obsqg@4ax.com> <h0ib6j576v8o37qu1ojrsmeb5o88f29upe@4ax.com> <2024Jun9.185245@mips.complang.tuwien.ac.at> <38ob6jl9sl3ceb0qugaf26cbv8lk7hmdil@4ax.com> <2024Jun10.091648@mips.complang.tuwien.ac.at> <o32f6jlq2qpi9s1u8giq521vv40uqrkiod@4ax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="3811913"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$EqwPKooGacTPf1MSSABeSuaLH9sUrsK4KMwRo27Ad4MHSevqnSzCy
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
Bytes: 5201
Lines: 89

John Savard wrote:

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

Timeline:: the microarchitecture of Intel's latest chips are derived
all the way back to Pentium Pro. Sure they have tweaked lots of 
things and created an explosion of new instructions, but deep inside
it is still PP.

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

Yes

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

In the course of accessing data from the cache, one also has to check
if
there is an outstanding request to memory for this same cache line. So,
when multiple requests all target the same cache line, one only fetches
it once. This check is performed fully associatively in the miss
buffer.
Since one is already checking the miss buffer, and the miss buffer has
to have any cache line pass through it during instruction execution::

ALL I have DONE is to not have the MB write into the cache until the
causing instruction retires !! Should the instruction NOT retire, the
data in the miss buffer can be delivered back to memory/whence it came
(depending on coherence protocol) and we remain coherent without::
a) delaying the core
b) modifying the cache
c) exposing microarchitectural details

The only piece of logic that needs to change is the miss buffer in that
they currently only deliver the "critical word" of the miss and then
dump the buffer into the cache. All I ask is for the miss buffer to 
deliver data to all outstanding requests while initiator is waiting 
to retire. {This may need an extra entry (or 2) in MB to avoid losing
performance.

Intel and AMD (and everyone else it appears) have not done a major
new microarchitecture since Spectré was announced {they may NOT even
CARE !} Instead of new microarchitecture, they prefer to add o the
width and depth of the execution window {not that anyone would
disagree).

Noting in My 66000 requires and serious modification to the GBOoO
general architecture of the execution window--just modifications to
some sequences to prevent microarchitectural leakage.

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

My 66000 is also insensitive to RowHammer and derivatives.....

> John Savard