Path: ...!feed.opticnetworks.net!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: Tue, 11 Jun 2024 13:27:35 -0600
Organization: A noiseless patient Spider
Lines: 71
Message-ID: <k58h6jlvp9rl13br6v1t24t47t4t2brfiv@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> <o32f6jlq2qpi9s1u8giq521vv40uqrkiod@4ax.com> <3a691dbdc80ebcc98d69c3a234f4135b@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 11 Jun 2024 21:27:38 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f752231138247ec5b6f53ce61cda1d0c";
	logging-data="1275443"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18ZvLwmMeBm5LpFYWTcOs0zQ9fYUAvkRRM="
Cancel-Lock: sha1:Wj0tzJoZGDe0we95SGpSYtAgOdQ=
X-Newsreader: Forte Free Agent 3.3/32.846
Bytes: 4271

On Tue, 11 Jun 2024 00:27:02 +0000, mitchalsup@aol.com (MitchAlsup1)
wrote:

>ALL I have DONE is to not have the MB write into the cache until the
>causing instruction retires !!

I suppose that depends on how you define "write".

If by "write" you mean store data in the cache, for eventual writing
out into RAM, well, since RAM doesn't contain "rename locations" to
play with, it seems to me that any CPU designer had better do that.

At least, I'm not imaginative enough to think of doing it any other
way.

However, if by "write" you mean to change the state of the cache in
any way, such as by reading data from memory... now, _then_ you would
indeed have done what is necessary to combat Spectre.

Obviously, though, a "load" instruction will _never_ retire unless it
can read the data from memory it is trying to put in a register.

So apparently WHAT you have REALLY DONE is to modify how memory reads
work...

if the data a load instruction requires is not already in the cache,
then a direct read from memory is performed which *completely
bypasses* the cache; this data (and its associated address) are
retained by the CPU to be placed in the cache _if_ the instruction is
actually executed and when it retires.

And, in fact, the various cache levels have to work this way too. You
have an L1 cache miss, but an L2 cache hit? Fine, you take your data
directly from L2, and don't promote the data into L2 until instruction
retirement.

So now the process of fetching data from memory is _not_ done by
fetching always from L1 and going _throughl_ L1 to access L2, and
going _through_ L2 to access RAM, which seems to be the usual way
these days.

That certainly can be done. But it isn't quite as simple and obvious
as you seem to claim.

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

When I first read that sentence, I was completely incredulous. DRAM is
sensitive to RowHammer because it's gone to feature sizes which are
beyond the state-of-the-art to do properly... so corners have been
cut.

How a CPU can be "insensitive" to it was mysterious.

After all, RowHammer is caused by multiple rapid-fire accesses to the
same address, or to related addresses, in memory.

But given that you are now explicitly passing accesses to DRAM around
the caches, instead of having the caches access DRAM as needed,
perhaps that also makes it possible for the CPU to detect suspicious
behavior more easily. (Since _relateld_ accesses may be used in a
RowHammer attack, simply pruning redundant memory accesses from the
operation stream won't be enough. I could see you doing _that_ as part
of "doing it right".)

If the "row" that was "hammered" just consisted of the 16 consecutive
locations that can be accessed speedily after the first one is ready,
then pruning reduntant accesses _would_ be enough, since to "hammer" a
row one has to access it hundreds of times, not at most 32 times; but
I'm afraid that isn't the case.

John Savard