Re: Privilege Levels Below User

John Savard wrote:

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

I mean the memory cell does not get modified.

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.

The cache itself is not modified until the memory reference retires.
But there is a buffer holding the data which can be accessed as if
it were an L0 cache until the data migrates to the real cache at retirement.

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.

The cache is not modified, the data is available through another means.
a means that can be backed up like a mispredicted branch. The buffer
I am talking about is temporally organized not spatially organized.

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

The LD instruction can obtain data from either the buffer or from
the data cache itself. The buffer covers the execution window,
allowing the LD to retire (assuming every older instruction also
retires).

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

I pipelined them through a temporally organized memory execution
window. This also provides for allowing the memory system to run
OoO wrt program order, and detect actual ordering violations, and
rerun the memory references in a proper memory order by rerunning
the references in order.
You get relaxed memory order performance and precise memory order
simultaneously.

if the data a load instruction requires is not already in the cache,
then a direct read from memory

The request is forwards towards memory through the cache hierarchy
and data arrives back at requestor (sooner or later).

                               is performed which *completely
bypasses* the cache;

Yes, critical word first.

                     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.

Yes !! While the data resides in the buffer, the whole line can be accessed by a number of memory reference instructions.

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.

I use an exclusive cache organization. so data arriving at the CPU
goes into buffer, which upon retirement goes into L1, which has the
potential to push a L1->L2 line, and so forth.

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.

Its back to the Athlon/Operon organizations.

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

If you had worked on them you can recognize the advantages and dis-
advantages.

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.

Yes, the write buffer in my DRAM controller is the L3 cache. Modified
data in the L3 migrates towards DRAM as DRAM cycles permit, but there
is no way to cause a line to be continuously be written into DRAM.
If a modified line has migrated to DRAM, and it gets modified again
in the L3, that 2nd write will not be performed until a refresh cycle
on that DRAM is performed.
Thus if one tries to RowHammer My 66000 DRAM, DRAM gets refresh cycle
between each write.

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

Banging on related cache lines also results in refresh cycles.

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.

I doubt that RowHammer still works when refreshes are interspersed
between accesses--RowHammer generally works because the events are
not protected by refreshes--the DRC sees the right ROW open and
simple streams at the open bank. Also note, there are no instructions in My 66000 that force a cache
to DRAM whereas there are instructions that can force a cache line
into L3. L3 is the buffer to DRAM. Nothing gets to DRAM without
going through L3 and nothing comes out of DRM that is not also
buffer by L3. So, if 96 cores simultaneously read a line residing in
DRAM, DRAM is read once and 95 cores are serviced through L3. So,
you can't RowHammer based on reading DRAM, either.

John Savard