Re: Privilege Levels Below User

On Mon, 21 Oct 2024 0:42:32 +0000, Paul A. Clayton wrote:

THREAD NECROMANCY
>
On 6/11/24 5:18 PM, MitchAlsup1 wrote:
[snip]

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.

>
If one refreshes the two adjacent rows to avoid data disruption,
those refreshes would be adjacent reads to two other rows so it
seems one would have to be a little cautious about excessively
frequent refreshes.
>

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.

>
How does a system suspend to DRAM if it cannot force a writeback
of all dirty lines to memory?

In GENERAL, you do not want to give this capability to applications
nor use it willy-nilly.

                              I am *guessing* this would not use a
special instruction but rather configuration of power management
that would cause hardware/firmware to clean the cache.

There is a sideband command from any master (anywhere) that causes
L3 to get dumped to DRAM over the next refresh interval. It is not
an instruction, and the TLB has to cooperate. A device may initiate
"suspend to DRAM" as well as a CPU (or any other bus master).

Writing back specific data to persistent memory might also
motivate cache block cleaning operations. Perhaps one could
implement such by copying from a cacheable mapping to a
non-cacheable(I/O?) memory?? (I simply remember that Intel added
instructions to write cache lines to persistent memory.)
>

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.

>
If 128 cores read distinct cache lines from the same page quickly
enough to hammer the adjacent pages but not quickly enough to get
DRAM page open hits, this would seem to require relatively
frequent refreshes of adjacent DRAM rows.

DDR 5 has a 64 GB/s transfer rate
128 cache lines (64B) is 8192 bytes
So this takes 1/8 of a millisecond or 125µs.
A DDR5 refresh interval is 3.9µs.
https://www.micron.com/content/dam/micron/global/public/products/white-paper/ddr5-new-features-white-paper.pdf#:~:text=REFRESH%20commands%20are%20issued%20at%20an%20average%20periodic,of%20295ns%20for%20a%2016Gb%20DDR5%20SDRAM%20device.
So one has refreshes in the described situation.

Since the L3/memory controller could see that the DRAM row was
unusually active, it could increase prefetching while the DRAM
row was open and/or queue the accesses longer so that the
hammering frequency was reduced and page open hits would be more
common.

A DRAM Row stays active, commands just CAS-out more data. That is
there is no ROW Hammering--the word line remains asserted while
the sense amplifiers remain asserted with captured data--while
CASs are used to strobe out ore data {subject to refresh}.

The simple statement that L3 would avoid RowHammer by providing
the same cache line to all requesters seemed a bit too simple.

You need to investigate the difference between RAS and CAS for
DRAMs.

Your design may very well handle all the problematic cases,
perhaps even with minimal performance penalties for inadvertent
hammering and logging/notification for questionable activity just
like for error correction (and has been proposed for detected race
conditions). I just know that these are hard problems.