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 20:50:14 +0000
Organization: Rocksolid Light
Message-ID: <a3cd9f92a284bcb239030a4e3b09af1f@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> <3a691dbdc80ebcc98d69c3a234f4135b@www.novabbs.org> <a1578792afb1bfeb694ec89e4092ee85@www.novabbs.org> <ks7h6jd7ind2e24l38frs4he3c7uea680j@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="3898090"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Rslight-Site: $2y$10$xAu8NXgopg2fwWGW44uHKetzhNFBe.ksis40btVOGrWUbmrcEX4QS
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 3560
Lines: 54

John Savard wrote:

> On Tue, 11 Jun 2024 00:45:28 +0000, mitchalsup@aol.com (MitchAlsup1)
> wrote:

>>I forgot to add that Mc 88120 had these features in 1992.

>>Stores waited for retirement.

> Given that in the case of external RAM, as opposed to registers inside
> the processor, there is only one possible value at any location...
> memory doesn't have a pile of rename locations to play with... I am so
> unimaginative that I don't think I could design a CPU in which stores
> to RAM didn't wait for the instruction that performed them to retire.

I never said it did. Effectively, there is a buffer that feeds the OoO
engine results as early as possible (acting like a cache, but a cache
withy the property that it can be discarded (in part or whole) just
like
instructions in the shadow of a branch can be discarded.) So, the
pipeline
gets fed by the buffer and the update of the actual cache is delayed
until
the instruction causing the event to retire.

So depending on where you look you can see the front of the pipeline or
the end of the pipeline--and it works the exact same way as branch
pred-
iction and with the same property that one can back up to some sane
point
based on external events (coherent messages,...) rather than branch
mis-
prediction.

> That, though, wouldn't save me from Spectre, since Spectre leaks
> information by virtue of fetches of stuff _read_ in earlier speculated
> code that didn't really happen being in cache.

Here, Spectré performs back to back dependent LDs, by doing these many 
times in a row, and prediction mechanism will lock in on these
instructions
being OK to execute.

Then, the first LD returns a pointer while the TLB returns "bad access"
But the loaded pointer goes through AGEN before permissions have been
fully checked. This second LD is not allowed to modify the data cache;
or Spectré can see this microarchitectural state change.

When the bad LD is discarded from execution so is the damage done by
the second LD--its data is discarded from the buffer and never makes 
it to the cache. Instruction entering the pipeline after do not see 
the data that should have never been there. Q.E.D. no Spectré sensi-
tivity.

> John Savard