On Mon, 12 Feb 2024 20:27:13 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

> Michael S <already5chosen@yahoo.com> writes:
> >On Sun, 11 Feb 2024 19:57:34 +0000
> >mitchalsup@aol.com (MitchAlsup1) wrote:
>
> >Because memory controller is not aware of CPU page boundaries.
> >Besides, in aarch64 world 16KB pages are rather common. And in x86
> >world "transparent huge pages" are rather common.
>
> AArch64 supports translation granules of 4k, 16k and 64k. 4K
> and 64K are the most common. While the architecture defines
> 16k, an implementation is free to not support it and I'm not aware of
> any widespread usage.

I think, 16KB is the main page size on Apple. Android is trying the
same, but so far has problems.
Apple+Android == approximately 101% of AArch64 total.

Michael S wrote:

> On Sun, 11 Feb 2024 19:57:34 +0000
> mitchalsup@aol.com (MitchAlsup1) wrote:

>> EricP wrote:
>>
>> > MitchAlsup1 wrote:
>> >> EricP wrote:
>> >>
>> >>> Anton Ertl wrote:
>> >>>> mitchalsup@aol.com (MitchAlsup1) writes:
>> >>>>> Anton Ertl wrote:
>> >>
>> >>>> Both disadvantages lead to far more refreshes than necessary to
>> >>>> prevent Rowhammer, but that approach may still be good enough.
>> >>
>> >> Would you rather have a few more refreshes or a few more ECC
>> >> repairs ?!? with the potential for a few ECC repair fails ?!!?
>>
>> > I believe Rowhammer and RowPress can flip many bits at once.
>> > Too many for SECDED.
>>
>> >>> Lets see how bad this is.
>> >>
>> >>> The single line threshold of 4800 and blast radius of 8 = 600
>> >>> trigger count.
>> >>> That triggers an extra 8 row refreshes, so 8/600 = 1.3% overhead.
>> >>> And the whole dram is refreshed every 64 ms reseting all the
>> >>> counters so the counts are not cumulative.
>> >>
>> >> I think what RowPress tells us that waiting 60± ms and then
>> >> refreshing every row
>> >> is worse for data retention than spreading the refreshes out over
>> >> the 64ms max
>> >> interval rather evenly.
>>
>> > Would any memory controller that would do that,
>> > refresh the whole dram in one big burst instead of periodically by
>> > row? I would expect doing so would introduce big stalls into memory
>> > access.
>>
>> > 64 ms / 8192 rows per block = 7.8125 us row interval.
>>
>> My DRAM controller (Opteron RevF) had a timer set about 7µs and if the
>> back was active it would allow REF to slip. But on a second timer
>> event it would interrupt data transfer and induce 2 refreshes to
>> catch up. In general, this worked well as it almost never happened.
>>
>> > Lets say 50 ns row refresh time.
>> > So thats either 50 ns every 7.8 us
>>
>> A DDR5 at 6GBits/s transmits a 4096 byte page in 5µs.
>>

> DDR5 channel is 32-bit.
> 4096B/(4B/T * 6e9 T/s) = 0.171 usec.
> Or for more 0.204 usec for more realistic rate of 5e9 T/s

>> When one changes page boundaries the HoB address bits are essentially
>> randomized by the TLB:: why not just close the row at that point ?
>>

> Because memory controller is not aware of CPU page boundaries.

Bits<19:12> changed. How hard is that to detect ??

> Besides, in aarch64 world 16KB pages are rather common. And in x86
> world "transparent huge pages" are rather common.

Neither of which prevent closing the row to avoid memory retention
issues.

>> > verses 8192*50 ns = 409.6 us memory stall every 64 ms.

On Mon, 12 Feb 2024 22:45:08 +0000
mitchalsup@aol.com (MitchAlsup1) wrote:

> Michael S wrote:
>
> > On Sun, 11 Feb 2024 19:57:34 +0000
> > mitchalsup@aol.com (MitchAlsup1) wrote:
>
> >> EricP wrote:
> >>
> >> > MitchAlsup1 wrote:
> >> >> EricP wrote:
> >> >>
> >> >>> Anton Ertl wrote:
> >> >>>> mitchalsup@aol.com (MitchAlsup1) writes:
> >> >>>>> Anton Ertl wrote:
> >> >>
> >> >>>> Both disadvantages lead to far more refreshes than necessary
> >> >>>> to prevent Rowhammer, but that approach may still be good
> >> >>>> enough.
> >> >>
> >> >> Would you rather have a few more refreshes or a few more ECC
> >> >> repairs ?!? with the potential for a few ECC repair fails ?!!?
> >> >>
> >>
> >> > I believe Rowhammer and RowPress can flip many bits at once.
> >> > Too many for SECDED.
> >>
> >> >>> Lets see how bad this is.
> >> >>
> >> >>> The single line threshold of 4800 and blast radius of 8 = 600
> >> >>> trigger count.
> >> >>> That triggers an extra 8 row refreshes, so 8/600 = 1.3%
> >> >>> overhead. And the whole dram is refreshed every 64 ms reseting
> >> >>> all the counters so the counts are not cumulative.
> >> >>
> >> >> I think what RowPress tells us that waiting 60± ms and then
> >> >> refreshing every row
> >> >> is worse for data retention than spreading the refreshes out
> >> >> over the 64ms max
> >> >> interval rather evenly.
> >>
> >> > Would any memory controller that would do that,
> >> > refresh the whole dram in one big burst instead of periodically
> >> > by row? I would expect doing so would introduce big stalls into
> >> > memory access.
> >>
> >> > 64 ms / 8192 rows per block = 7.8125 us row interval.
> >>
> >> My DRAM controller (Opteron RevF) had a timer set about 7µs and if
> >> the back was active it would allow REF to slip. But on a second
> >> timer event it would interrupt data transfer and induce 2
> >> refreshes to catch up. In general, this worked well as it almost
> >> never happened.
> >> > Lets say 50 ns row refresh time.
> >> > So thats either 50 ns every 7.8 us
> >>
> >> A DDR5 at 6GBits/s transmits a 4096 byte page in 5µs.
> >>
>
> > DDR5 channel is 32-bit.
> > 4096B/(4B/T * 6e9 T/s) = 0.171 usec.
> > Or for more 0.204 usec for more realistic rate of 5e9 T/s
>
> >> When one changes page boundaries the HoB address bits are
> >> essentially randomized by the TLB:: why not just close the row at
> >> that point ?
>
> > Because memory controller is not aware of CPU page boundaries.
>
> Bits<19:12> changed. How hard is that to detect ??
>

Do you always answer one statement before reading the next statement?

> > Besides, in aarch64 world 16KB pages are rather common. And in x86
> > world "transparent huge pages" are rather common.
>
> Neither of which prevent closing the row to avoid memory retention
> issues.
>

What scenario of attack do you have in mind?
I would think that neither in "classic" multi-side Row Hammer nor in Row
Press attacker has to cross CPU page boundaries. If he (attacker)
happens to know that memory controller likes to close DRAMraws on any
particular address boundary, then he can easily avoid accessing last
cache line before that particular boundary.

BTW, all this attacks (or should I say, all this POCs, because I don't
think that somebody ever caught real RH/RP attack launched by real bad
guy) rather heavily depend on big or huge pages. They are close to
impossible with small pages, even when "small" means 16 KB rather than
4 KB.

> >> > verses 8192*50 ns = 409.6 us memory stall every 64 ms.

Michael S wrote:

> On Mon, 12 Feb 2024 22:45:08 +0000
> mitchalsup@aol.com (MitchAlsup1) wrote:

>> Michael S wrote:
>>
>> > On Sun, 11 Feb 2024 19:57:34 +0000
>> > mitchalsup@aol.com (MitchAlsup1) wrote:
>>
>> >> EricP wrote:
>> >>
>> >> > MitchAlsup1 wrote:
>> >> >> EricP wrote:
>> >> >>
>> >> >>> Anton Ertl wrote:
>> >> >>>> mitchalsup@aol.com (MitchAlsup1) writes:
>> >> >>>>> Anton Ertl wrote:
>> >> >>
>> >> >>>> Both disadvantages lead to far more refreshes than necessary
>> >> >>>> to prevent Rowhammer, but that approach may still be good
>> >> >>>> enough.
>> >> >>
>> >> >> Would you rather have a few more refreshes or a few more ECC
>> >> >> repairs ?!? with the potential for a few ECC repair fails ?!!?
>> >> >>
>> >>
>> >> > I believe Rowhammer and RowPress can flip many bits at once.
>> >> > Too many for SECDED.
>> >>
>> >> >>> Lets see how bad this is.
>> >> >>
>> >> >>> The single line threshold of 4800 and blast radius of 8 = 600
>> >> >>> trigger count.
>> >> >>> That triggers an extra 8 row refreshes, so 8/600 = 1.3%
>> >> >>> overhead. And the whole dram is refreshed every 64 ms reseting
>> >> >>> all the counters so the counts are not cumulative.
>> >> >>
>> >> >> I think what RowPress tells us that waiting 60± ms and then
>> >> >> refreshing every row
>> >> >> is worse for data retention than spreading the refreshes out
>> >> >> over the 64ms max
>> >> >> interval rather evenly.
>> >>
>> >> > Would any memory controller that would do that,
>> >> > refresh the whole dram in one big burst instead of periodically
>> >> > by row? I would expect doing so would introduce big stalls into
>> >> > memory access.
>> >>
>> >> > 64 ms / 8192 rows per block = 7.8125 us row interval.
>> >>
>> >> My DRAM controller (Opteron RevF) had a timer set about 7µs and if
>> >> the back was active it would allow REF to slip. But on a second
>> >> timer event it would interrupt data transfer and induce 2
>> >> refreshes to catch up. In general, this worked well as it almost
>> >> never happened.
>> >> > Lets say 50 ns row refresh time.
>> >> > So thats either 50 ns every 7.8 us
>> >>
>> >> A DDR5 at 6GBits/s transmits a 4096 byte page in 5µs.
>> >>
>>
>> > DDR5 channel is 32-bit.
>> > 4096B/(4B/T * 6e9 T/s) = 0.171 usec.
>> > Or for more 0.204 usec for more realistic rate of 5e9 T/s
>>
>> >> When one changes page boundaries the HoB address bits are
>> >> essentially randomized by the TLB:: why not just close the row at
>> >> that point ?
>>
>> > Because memory controller is not aware of CPU page boundaries.
>>
>> Bits<19:12> changed. How hard is that to detect ??
>>

> Do you always answer one statement before reading the next statement?

I actually wrote the above after writing the below.

>> > Besides, in aarch64 world 16KB pages are rather common. And in x86
>> > world "transparent huge pages" are rather common.
>>
>> Neither of which prevent closing the row to avoid memory retention
>> issues.
>>

> What scenario of attack do you have in mind?

RowPress depends on keeping the row open too long--clearly evident in the
charts in the document.

> I would think that neither in "classic" multi-side Row Hammer nor in Row
> Press attacker has to cross CPU page boundaries. If he (attacker)
> happens to know that memory controller likes to close DRAMraws on any
> particular address boundary, then he can easily avoid accessing last
> cache line before that particular boundary.

RowHammer depends on closing the row too often.

Performance (single CPU) depends on allowing the open row to service
several pending requests streaming data at CAS access speeds.

There is a balance to be found by preventing RowHammer from opening
nearby rows too often and in preventing RowPress from holding them
open for too long.

I happen to think (without evidence beyond that of the rRowPress document)
that the balance is distributing refreshes evenly across the refresh
interval (as evidenced in the charts in RowPress document. It ends up
that with modern DDR this enables about 4096 bytes to be read/written
to a row before closing it (within a factor of 2-4).

> BTW, all this attacks (or should I say, all this POCs, because I don't
> think that somebody ever caught real RH/RP attack launched by real bad
> guy) rather heavily depend on big or huge pages. They are close to
> impossible with small pages, even when "small" means 16 KB rather than
> 4 KB.

>> >> > verses 8192*50 ns = 409.6 us memory stall every 64 ms.

On Tue, 13 Feb 2024 00:19:18 +0000
mitchalsup@aol.com (MitchAlsup1) wrote:

> Michael S wrote:
>
> > On Mon, 12 Feb 2024 22:45:08 +0000
> > mitchalsup@aol.com (MitchAlsup1) wrote:
>
> >> Michael S wrote:
> >>
> >> > On Sun, 11 Feb 2024 19:57:34 +0000
> >> > mitchalsup@aol.com (MitchAlsup1) wrote:
> >>
> >> >> EricP wrote:
> >> >>
> >> >> > MitchAlsup1 wrote:
> >> >> >> EricP wrote:
> >> >> >>
> >> >> >>> Anton Ertl wrote:
> >> >> >>>> mitchalsup@aol.com (MitchAlsup1) writes:
> >> >> >>>>> Anton Ertl wrote:
> >> >> >>
> >> >> >>>> Both disadvantages lead to far more refreshes than
> >> >> >>>> necessary to prevent Rowhammer, but that approach may
> >> >> >>>> still be good enough.
> >> >> >>
> >> >> >> Would you rather have a few more refreshes or a few more ECC
> >> >> >> repairs ?!? with the potential for a few ECC repair fails
> >> >> >> ?!!?
> >> >>
> >> >> > I believe Rowhammer and RowPress can flip many bits at once.
> >> >> > Too many for SECDED.
> >> >>
> >> >> >>> Lets see how bad this is.
> >> >> >>
> >> >> >>> The single line threshold of 4800 and blast radius of 8 > >> >> >>> 600 trigger count.
> >> >> >>> That triggers an extra 8 row refreshes, so 8/600 = 1.3%
> >> >> >>> overhead. And the whole dram is refreshed every 64 ms
> >> >> >>> reseting all the counters so the counts are not cumulative.
> >> >> >>>
> >> >> >>
> >> >> >> I think what RowPress tells us that waiting 60± ms and then
> >> >> >> refreshing every row
> >> >> >> is worse for data retention than spreading the refreshes out
> >> >> >> over the 64ms max
> >> >> >> interval rather evenly.
> >> >>
> >> >> > Would any memory controller that would do that,
> >> >> > refresh the whole dram in one big burst instead of
> >> >> > periodically by row? I would expect doing so would introduce
> >> >> > big stalls into memory access.
> >> >>
> >> >> > 64 ms / 8192 rows per block = 7.8125 us row interval.
> >> >>
> >> >> My DRAM controller (Opteron RevF) had a timer set about 7µs and
> >> >> if the back was active it would allow REF to slip. But on a
> >> >> second timer event it would interrupt data transfer and induce 2
> >> >> refreshes to catch up. In general, this worked well as it almost
> >> >> never happened.
> >> >> > Lets say 50 ns row refresh time.
> >> >> > So thats either 50 ns every 7.8 us
> >> >>
> >> >> A DDR5 at 6GBits/s transmits a 4096 byte page in 5µs.
> >> >>
> >>
> >> > DDR5 channel is 32-bit.
> >> > 4096B/(4B/T * 6e9 T/s) = 0.171 usec.
> >> > Or for more 0.204 usec for more realistic rate of 5e9 T/s
> >>
> >> >> When one changes page boundaries the HoB address bits are
> >> >> essentially randomized by the TLB:: why not just close the row
> >> >> at that point ?
> >>
> >> > Because memory controller is not aware of CPU page boundaries.
> >> >
> >>
> >> Bits<19:12> changed. How hard is that to detect ??
> >>
>
> > Do you always answer one statement before reading the next
> > statement?
>
> I actually wrote the above after writing the below.
>
> >> > Besides, in aarch64 world 16KB pages are rather common. And in
> >> > x86 world "transparent huge pages" are rather common.
> >>
> >> Neither of which prevent closing the row to avoid memory retention
> >> issues.
> >>
>
> > What scenario of attack do you have in mind?
>
> RowPress depends on keeping the row open too long--clearly evident in
> the charts in the document.
>

Clarification for casual observers that didn't bother to read Row Press
paper: RowPress attack does not depends on keeping row open
continuously.
Short interruptions actually greatly improve effectiveness of attack
significantly increasing BER for a given duration of attack. After
all, RowPress *is* a variant of RowHammer.
For a given interruption rate, longer interruptions reduce effectiveness
of attack, but not dramatically so. For example, for most practically
important interruption rate of 128 KHz (period=7.81 usec) increasing
duration of off interval from absolute minimum allowed by protocol
(~50ns) to 2 usec reduces efficiency of attack only by factor of 2 o 3.

> > I would think that neither in "classic" multi-side Row Hammer nor
> > in Row Press attacker has to cross CPU page boundaries. If he
> > (attacker) happens to know that memory controller likes to close
> > DRAMraws on any particular address boundary, then he can easily
> > avoid accessing last cache line before that particular boundary.
>
> RowHammer depends on closing the row too often.
>

Yes, except that it is unknown whether major RH impact is done by
closing the row or by opening it. The later is more likely. But since
the rate of opening and closing is the same, this finer difference is
not important.

> Performance (single CPU) depends on allowing the open row to service
> several pending requests streaming data at CAS access speeds.
>
> There is a balance to be found by preventing RowHammer from opening
> nearby rows too often and in preventing RowPress from holding them
> open for too long.
>

There is no balance. Opening nearby rows too often helps both variants
of attack.

> I happen to think (without evidence beyond that of the rRowPress
> document) that the balance is distributing refreshes evenly across
> the refresh interval (as evidenced in the charts in RowPress
> document. It ends up that with modern DDR this enables about 4096
> bytes to be read/written to a row before closing it (within a factor
> of 2-4).
>

Huh?
DDR4-3200 channel transfers data at rate approaching 25.6 GB/s. DDR5
will be the same when it reaches it's projected maximum speed of 6400.
25.6 GB/s * 7.81 usec = 200,000 bytes. That's a factor of 49 rather than
2-4.

Michael S wrote:
> On Tue, 13 Feb 2024 00:19:18 +0000
> mitchalsup@aol.com (MitchAlsup1) wrote:
>> RowPress depends on keeping the row open too long--clearly evident in
>> the charts in the document.
>>
>
> Clarification for casual observers that didn't bother to read Row Press
> paper: RowPress attack does not depends on keeping row open
> continuously.
> Short interruptions actually greatly improve effectiveness of attack
> significantly increasing BER for a given duration of attack. After
> all, RowPress *is* a variant of RowHammer.

RowPress documents that keeping the aggressor row open longer lowers
the limit on the adjacent rows before opens (RowHammers) causes bit flips.
Also the paper notes that DRAM manufacturers, eg Micron and Samsung,
already document that keeping a row open longer can cause read-disturbance.
What's new is the paper documents the interaction between row activation
time and the subsequent number of opens (RowHammers) needed to flip a bit.

Also note that different bits are susceptible to RowPress and RowHammer.
See section 4.3

RowPress Amplifying Read Disturbance in Modern DRAM Chips, 2023
https://people.inf.ethz.ch/omutlu/pub/RowPress_isca23.pdf

"RowPress breaks memory isolation by keeping a DRAM row open for a long
period of time, which disturbs physically nearby rows enough to cause
bitflips. We show that RowPress amplifies DRAM’s vulnerability to
read-disturb attacks by significantly reducing the number of row
activations needed to induce a bitflip by one to two orders of
magnitude under realistic conditions. In extreme cases, RowPress induces
bitflips in a DRAM row when an adjacent row is activated only once."

"We show that keeping a DRAM row (i.e., aggressor row) open for a long
period of time (i.e., a large aggressor row ON time, tAggON) disturbs
physically nearby DRAM rows. Doing so induces bitflips in the victim row
without requiring (tens of) thousands of activations to the aggressor row."

> For a given interruption rate, longer interruptions reduce effectiveness
> of attack, but not dramatically so. For example, for most practically
> important interruption rate of 128 KHz (period=7.81 usec) increasing
> duration of off interval from absolute minimum allowed by protocol
> (~50ns) to 2 usec reduces efficiency of attack only by factor of 2 o 3.

Reduced by a factor of up to 363. Under figure 1.

"We observe that as tAggON increases, compared to the most effective
RowHammer pattern, the most effective Row-Press pattern reduces ACmin
1) by 17.6× on average (up to 40.7×) when tAggON is as large as the
refresh interval (7.8 μs),
2) by 159.4× on average (up to 363.8×) when tAggON is 70.2 μs,
the maximum allowed tAggON, and
3) down to only one activation for an extreme tAggON of 30 ms
(highlighted by dashed red boxes).

Also see "Obsv. 1. RowPress significantly reduces ACmin as tAggON increases."

On Tue, 13 Feb 2024 11:24:10 -0500
EricP <ThatWouldBeTelling@thevillage.com> wrote:

> Michael S wrote:
> > On Tue, 13 Feb 2024 00:19:18 +0000
> > mitchalsup@aol.com (MitchAlsup1) wrote:
> >> RowPress depends on keeping the row open too long--clearly evident
> >> in the charts in the document.
> >>
> >
> > Clarification for casual observers that didn't bother to read Row
> > Press paper: RowPress attack does not depends on keeping row open
> > continuously.
> > Short interruptions actually greatly improve effectiveness of attack
> > significantly increasing BER for a given duration of attack. After
> > all, RowPress *is* a variant of RowHammer.
>
> RowPress documents that keeping the aggressor row open longer lowers
> the limit on the adjacent rows before opens (RowHammers) causes bit
> flips.

Correct, but irrelevant.

> Also the paper notes that DRAM manufacturers, eg Micron and
> Samsung, already document that keeping a row open longer can cause
> read-disturbance. What's new is the paper documents the interaction
> between row activation time and the subsequent number of opens
> (RowHammers) needed to flip a bit.
>

Correct and relevant, but not to the issue at hand which is criticism
of Mitch's ideas of mitigation.

> Also note that different bits are susceptible to RowPress and
> RowHammer. See section 4.3
>
> RowPress Amplifying Read Disturbance in Modern DRAM Chips, 2023
> https://people.inf.ethz.ch/omutlu/pub/RowPress_isca23.pdf
>
> "RowPress breaks memory isolation by keeping a DRAM row open for a
> long period of time, which disturbs physically nearby rows enough to
> cause bitflips. We show that RowPress amplifies DRAM’s vulnerability
> to read-disturb attacks by significantly reducing the number of row
> activations needed to induce a bitflip by one to two orders of
> magnitude under realistic conditions. In extreme cases, RowPress
> induces bitflips in a DRAM row when an adjacent row is activated only
> once."
>
> "We show that keeping a DRAM row (i.e., aggressor row) open for a long
> period of time (i.e., a large aggressor row ON time, tAggON) disturbs
> physically nearby DRAM rows. Doing so induces bitflips in the victim
> row without requiring (tens of) thousands of activations to the
> aggressor row."
>
> > For a given interruption rate, longer interruptions reduce
> > effectiveness of attack, but not dramatically so. For example, for
> > most practically important interruption rate of 128 KHz
> > (period=7.81 usec) increasing duration of off interval from
> > absolute minimum allowed by protocol (~50ns) to 2 usec reduces
> > efficiency of attack only by factor of 2 o 3.
>
> Reduced by a factor of up to 363. Under figure 1.
>
> "We observe that as tAggON increases, compared to the most effective
> RowHammer pattern, the most effective Row-Press pattern reduces ACmin
> 1) by 17.6× on average (up to 40.7×) when tAggON is as large as the
> refresh interval (7.8 μs),
> 2) by 159.4× on average (up to 363.8×) when tAggON is 70.2 μs,
> the maximum allowed tAggON, and
> 3) down to only one activation for an extreme tAggON of 30 ms
> (highlighted by dashed red boxes).
>
> Also see "Obsv. 1. RowPress significantly reduces ACmin as tAggON
> increases."
>

ACmin by itself is a wrong measure of efficiency of attack.
The right measure is reciprocal of the total duration of attack.
At any given duty cycle reciprocal of the total duration of attack
grows with increased rate of interruptions (a.k.a. hammering rate).
The general trend is the same as for all other RH variants, the only
difference that dependency on hammering rate is somewhat weaker.

Relatively weak influence of duty cycle itself is shown in figure 22.

The practical significance of RowPress is due to two factors.
(1) is the factor is the one you mentioned above - it can flip
different bits from those flippable by other RH variants.
(2) is that it is not affected at all by DDR4 TRR
attempt of mitigation.

The third, less important factor is that RowPress appears quite robust
to differences between major manufacturers.

However, one should not overlook that efficiency of RowPress attacks
when measured by the most important criterion of BER per duration of
attack is many times lower than earlier techniques of double-sided and
multi-sided hammering.

Michael S wrote:
> On Tue, 13 Feb 2024 00:19:18 +0000
> mitchalsup@aol.com (MitchAlsup1) wrote:
>> RowHammer depends on closing the row too often.
>
> Yes, except that it is unknown whether major RH impact is done by
> closing the row or by opening it. The later is more likely. But since
> the rate of opening and closing is the same, this finer difference is
> not important.

A Deeper Look into RowHammers Sensitivities Experimental Analysis
of Real DRAM Chips and Implications on Future Attacks and Defenses, 2021
https://arxiv.org/pdf/2110.10291

That paper pre-dates the RowPress one and notes:

"6.1 Impact of Aggressor Row’s On-Time

Obsv. 8. As the aggressor row stays active longer (i.e., tAggON increases),
more DRAM cells experience RowHammer bit flips and they
experience RowHammer bit flips at lower hammer counts."

Obsv. 9. RowHammer vulnerability consistently worsens as tAggON
increases in DRAM chips from all four manufacturers.

6.2 Impact of Aggressor Row’s Off-Time

Obsv. 10. As the bank stays precharged longer (i.e., tAggOFF increases),
fewer DRAM cells experience RowHammer bit flips and they
experience RowHammer bit flips at higher hammer counts.

Obsv. 11. RowHammer vulnerability consistently reduces as
tAggOFF increases in DRAM chips from all four manufacturers."

On Tue, 13 Feb 2024 12:05:18 -0500
EricP <ThatWouldBeTelling@thevillage.com> wrote:

> Michael S wrote:
> > On Tue, 13 Feb 2024 00:19:18 +0000
> > mitchalsup@aol.com (MitchAlsup1) wrote:
> >> RowHammer depends on closing the row too often.
> >
> > Yes, except that it is unknown whether major RH impact is done by
> > closing the row or by opening it. The later is more likely. But
> > since the rate of opening and closing is the same, this finer
> > difference is not important.
>
> A Deeper Look into RowHammers Sensitivities Experimental Analysis
> of Real DRAM Chips and Implications on Future Attacks and Defenses,
> 2021 https://arxiv.org/pdf/2110.10291
>
> That paper pre-dates the RowPress one and notes:
>
> "6.1 Impact of Aggressor Row’s On-Time
>
> Obsv. 8. As the aggressor row stays active longer (i.e., tAggON
> increases), more DRAM cells experience RowHammer bit flips and they
> experience RowHammer bit flips at lower hammer counts."
>
> Obsv. 9. RowHammer vulnerability consistently worsens as tAggON
> increases in DRAM chips from all four manufacturers.
>
> 6.2 Impact of Aggressor Row’s Off-Time
>
> Obsv. 10. As the bank stays precharged longer (i.e., tAggOFF
> increases), fewer DRAM cells experience RowHammer bit flips and they
> experience RowHammer bit flips at higher hammer counts.
>
> Obsv. 11. RowHammer vulnerability consistently reduces as
> tAggOFF increases in DRAM chips from all four manufacturers."
>
>
>
>
>
>

novaBBS is not updating since yesterday, so Mitch is not aware of
our latest posts.

Michael S wrote:
> On Tue, 13 Feb 2024 11:24:10 -0500
> EricP <ThatWouldBeTelling@thevillage.com> wrote:
>> Michael S wrote:
>>> On Tue, 13 Feb 2024 00:19:18 +0000
>>> mitchalsup@aol.com (MitchAlsup1) wrote:
>>>> RowPress depends on keeping the row open too long--clearly evident
>>>> in the charts in the document.
>>>>
>>> Clarification for casual observers that didn't bother to read Row
>>> Press paper: RowPress attack does not depends on keeping row open
>>> continuously.
>>> Short interruptions actually greatly improve effectiveness of attack
>>> significantly increasing BER for a given duration of attack. After
>>> all, RowPress *is* a variant of RowHammer.
>> RowPress documents that keeping the aggressor row open longer lowers
>> the limit on the adjacent rows before opens (RowHammers) causes bit
>> flips.
>
> Correct, but irrelevant.

It was kinda the whole point of the RowPress paper.

>> Also the paper notes that DRAM manufacturers, eg Micron and
>> Samsung, already document that keeping a row open longer can cause
>> read-disturbance. What's new is the paper documents the interaction
>> between row activation time and the subsequent number of opens
>> (RowHammers) needed to flip a bit.
>>
>
> Correct and relevant, but not to the issue at hand which is criticism
> of Mitch's ideas of mitigation.
>
>> Also note that different bits are susceptible to RowPress and
>> RowHammer. See section 4.3
>>
>> RowPress Amplifying Read Disturbance in Modern DRAM Chips, 2023
>> https://people.inf.ethz.ch/omutlu/pub/RowPress_isca23.pdf

I just found out that there are two different versions of the RowPress
paper and I was looking at the older one. The updated version is:

RowPress: Amplifying Read Disturbance in Modern DRAM Chips, 2023
https://arxiv.org/pdf/2306.17061.pdf

>>> For a given interruption rate, longer interruptions reduce
>>> effectiveness of attack, but not dramatically so. For example, for
>>> most practically important interruption rate of 128 KHz
>>> (period=7.81 usec) increasing duration of off interval from
>>> absolute minimum allowed by protocol (~50ns) to 2 usec reduces
>>> efficiency of attack only by factor of 2 o 3.
>> Reduced by a factor of up to 363. Under figure 1.
>>
>> "We observe that as tAggON increases, compared to the most effective
>> RowHammer pattern, the most effective Row-Press pattern reduces ACmin
>> 1) by 17.6× on average (up to 40.7×) when tAggON is as large as the
>> refresh interval (7.8 μs),
>> 2) by 159.4× on average (up to 363.8×) when tAggON is 70.2 μs,
>> the maximum allowed tAggON, and
>> 3) down to only one activation for an extreme tAggON of 30 ms
>> (highlighted by dashed red boxes).
>>
>> Also see "Obsv. 1. RowPress significantly reduces ACmin as tAggON
>> increases."
>>
>
> ACmin by itself is a wrong measure of efficiency of attack.

I'm not interested in the efficiency of the attack.
ACmin, the minimum absolute count of opens above which we lose data
is the number I'm interested in.

> The right measure is reciprocal of the total duration of attack.
> At any given duty cycle reciprocal of the total duration of attack
> grows with increased rate of interruptions (a.k.a. hammering rate).
> The general trend is the same as for all other RH variants, the only
> difference that dependency on hammering rate is somewhat weaker.
>
> Relatively weak influence of duty cycle itself is shown in figure 22.

Looking at figure 22 on the arxiv version of the paper,
this is a completely different test. This test was to explain the
discrepancy between the RowPress results and the earlier cited papers.

BER is the fraction of DRAM cells in a DRAM row that experience bitflips.
Its a different measure because RowPress detects when ANY data loss begins,
not the fraction of lost data bits (efficiency) after it kicks in.

Obsv 16 explains it, the BER for the bottom two lines,
which are the ones with a long total tA2A, goes up in all graphs
by between a factor of 10 to about 500, which is the RowPress effect.

To my eye what this test shows is the PRE phase may *heal* some of the
damaging effects that the ACT phase causes, but only to a certain point.
Possibly the PRE phase scavenges the ACT hot injection carriers.

> The practical significance of RowPress is due to two factors.
> (1) is the factor is the one you mentioned above - it can flip
> different bits from those flippable by other RH variants.
> (2) is that it is not affected at all by DDR4 TRR
> attempt of mitigation.

I take away something completely different: there are multiple interacting
error mechanisms at work here. RowHammer and RowPress are likely
completely different physics and fixing one won't fix the other.

It also suggests there may be other similar mechanisms waiting to be found.

> The third, less important factor is that RowPress appears quite robust
> to differences between major manufacturers.
>
> However, one should not overlook that efficiency of RowPress attacks
> when measured by the most important criterion of BER per duration of
> attack is many times lower than earlier techniques of double-sided and
> multi-sided hammering.

For me the BER is irrelevant if it is above 0.0.
I want to know where the errors start which is ACmin.

On Wed, 14 Feb 2024 10:51:47 -0500
EricP <ThatWouldBeTelling@thevillage.com> wrote:

> Michael S wrote:
> > On Tue, 13 Feb 2024 11:24:10 -0500
> > EricP <ThatWouldBeTelling@thevillage.com> wrote:
> >> Michael S wrote:
> >>> On Tue, 13 Feb 2024 00:19:18 +0000
> >>> mitchalsup@aol.com (MitchAlsup1) wrote:
> >>>> RowPress depends on keeping the row open too long--clearly
> >>>> evident in the charts in the document.
> >>>>
> >>> Clarification for casual observers that didn't bother to read Row
> >>> Press paper: RowPress attack does not depends on keeping row open
> >>> continuously.
> >>> Short interruptions actually greatly improve effectiveness of
> >>> attack significantly increasing BER for a given duration of
> >>> attack. After all, RowPress *is* a variant of RowHammer.
> >> RowPress documents that keeping the aggressor row open longer
> >> lowers the limit on the adjacent rows before opens (RowHammers)
> >> causes bit flips.
> >
> > Correct, but irrelevant.
>
> It was kinda the whole point of the RowPress paper.
>
> >> Also the paper notes that DRAM manufacturers, eg Micron and
> >> Samsung, already document that keeping a row open longer can cause
> >> read-disturbance. What's new is the paper documents the interaction
> >> between row activation time and the subsequent number of opens
> >> (RowHammers) needed to flip a bit.
> >>
> >
> > Correct and relevant, but not to the issue at hand which is
> > criticism of Mitch's ideas of mitigation.
> >
> >> Also note that different bits are susceptible to RowPress and
> >> RowHammer. See section 4.3
> >>
> >> RowPress Amplifying Read Disturbance in Modern DRAM Chips, 2023
> >> https://people.inf.ethz.ch/omutlu/pub/RowPress_isca23.pdf
>
> I just found out that there are two different versions of the RowPress
> paper and I was looking at the older one. The updated version is:
>
> RowPress: Amplifying Read Disturbance in Modern DRAM Chips, 2023
> https://arxiv.org/pdf/2306.17061.pdf
>
> >>> For a given interruption rate, longer interruptions reduce
> >>> effectiveness of attack, but not dramatically so. For example, for
> >>> most practically important interruption rate of 128 KHz
> >>> (period=7.81 usec) increasing duration of off interval from
> >>> absolute minimum allowed by protocol (~50ns) to 2 usec reduces
> >>> efficiency of attack only by factor of 2 o 3.
> >> Reduced by a factor of up to 363. Under figure 1.
> >>
> >> "We observe that as tAggON increases, compared to the most
> >> effective RowHammer pattern, the most effective Row-Press pattern
> >> reduces ACmin 1) by 17.6× on average (up to 40.7×) when tAggON is
> >> as large as the refresh interval (7.8 μs),
> >> 2) by 159.4× on average (up to 363.8×) when tAggON is 70.2 μs,
> >> the maximum allowed tAggON, and
> >> 3) down to only one activation for an extreme tAggON of 30 ms
> >> (highlighted by dashed red boxes).
> >>
> >> Also see "Obsv. 1. RowPress significantly reduces ACmin as tAggON
> >> increases."
> >>
> >
> > ACmin by itself is a wrong measure of efficiency of attack.
>
> I'm not interested in the efficiency of the attack.
> ACmin, the minimum absolute count of opens above which we lose data
> is the number I'm interested in.
>

You may be interested, but I don't understand why.
For me, the important thing is how much time it take until probability
of the flip become significant.
Suppose, attack (A) hammers at 5 MHz and has ACmin=5e4. Attack (B)
hammers at 0.13 MHz (typical for RP in real-world setup) and has
ACmin=3e3.
Then I'd say that attack (A) is 2.3 times more dangerous.

Back to real world, researchers demonstrated that multi-side
hammering can have ACmin that is significantly lower than our imaginary
attack (A), so the only remaining question is how fast can we hammer
without triggering TRR. My 5MHz number probably hard to achieve for
attacker, but 2-3 MHz sound doable.

> > The right measure is reciprocal of the total duration of attack.
> > At any given duty cycle reciprocal of the total duration of attack
> > grows with increased rate of interruptions (a.k.a. hammering rate).
> > The general trend is the same as for all other RH variants, the only
> > difference that dependency on hammering rate is somewhat weaker.
> >
> > Relatively weak influence of duty cycle itself is shown in figure
> > 22.
>
> Looking at figure 22 on the arxiv version of the paper,
> this is a completely different test. This test was to explain the
> discrepancy between the RowPress results and the earlier cited papers.
>
> BER is the fraction of DRAM cells in a DRAM row that experience
> bitflips. Its a different measure because RowPress detects when ANY
> data loss begins, not the fraction of lost data bits (efficiency)
> after it kicks in.
>
> Obsv 16 explains it, the BER for the bottom two lines,
> which are the ones with a long total tA2A, goes up in all graphs
> by between a factor of 10 to about 500, which is the RowPress effect.
>
> To my eye what this test shows is the PRE phase may *heal* some of the
> damaging effects that the ACT phase causes, but only to a certain
> point. Possibly the PRE phase scavenges the ACT hot injection
> carriers.
>
> > The practical significance of RowPress is due to two factors.
> > (1) is the factor is the one you mentioned above - it can flip
> > different bits from those flippable by other RH variants.
> > (2) is that it is not affected at all by DDR4 TRR
> > attempt of mitigation.
>
> I take away something completely different: there are multiple
> interacting error mechanisms at work here. RowHammer and RowPress are
> likely completely different physics and fixing one won't fix the
> other.
>

Different like coupling in different frequency bands - yes.
But both caused by insufficient isolation.

> It also suggests there may be other similar mechanisms waiting to be
> found.
>
> > The third, less important factor is that RowPress appears quite
> > robust to differences between major manufacturers.
> >
> > However, one should not overlook that efficiency of RowPress attacks
> > when measured by the most important criterion of BER per duration of
> > attack is many times lower than earlier techniques of double-sided
> > and multi-sided hammering.
>
> For me the BER is irrelevant if it is above 0.0.
> I want to know where the errors start which is ACmin.
>

So, call it time to first flip. The principle is the same.
Still, MSRH causes harm faster than RP.

Michael S wrote:
> On Wed, 14 Feb 2024 10:51:47 -0500
> EricP <ThatWouldBeTelling@thevillage.com> wrote:
>> Michael S wrote:
>>> On Tue, 13 Feb 2024 11:24:10 -0500
>>> EricP <ThatWouldBeTelling@thevillage.com> wrote:
>>>>
>>>> "We observe that as tAggON increases, compared to the most
>>>> effective RowHammer pattern, the most effective Row-Press pattern
>>>> reduces ACmin 1) by 17.6× on average (up to 40.7×) when tAggON is
>>>> as large as the refresh interval (7.8 μs),
>>>> 2) by 159.4× on average (up to 363.8×) when tAggON is 70.2 μs,
>>>> the maximum allowed tAggON, and
>>>> 3) down to only one activation for an extreme tAggON of 30 ms
>>>> (highlighted by dashed red boxes).
>>>>
>>>> Also see "Obsv. 1. RowPress significantly reduces ACmin as tAggON
>>>> increases."
>>>>
>>> ACmin by itself is a wrong measure of efficiency of attack.
>> I'm not interested in the efficiency of the attack.
>> ACmin, the minimum absolute count of opens above which we lose data
>> is the number I'm interested in.
>
> You may be interested, but I don't understand why.
> For me, the important thing is how much time it take until probability
> of the flip become significant.

Because in terms of designing a memory controller
*any* bit flip due to RH or RP is unacceptable.
After RH/RP starts to inject errors the rate it does so
doesn't matter because the memory bank is corrupt.

> Suppose, attack (A) hammers at 5 MHz and has ACmin=5e4. Attack (B)
> hammers at 0.13 MHz (typical for RP in real-world setup) and has
> ACmin=3e3.
> Then I'd say that attack (A) is 2.3 times more dangerous.

That can tell you that dram A is more susceptible to a RH attack than B.

But what matters to a dram controller is whether ACmin opens can be
reached inside the refresh interval of 64 ms. After that minimum is reached,
how fast it corrupts memory in flips/sec is irrelevant since the number
of corrupted bits is more than are correctable by SECDED.

> Back to real world, researchers demonstrated that multi-side
> hammering can have ACmin that is significantly lower than our imaginary
> attack (A), so the only remaining question is how fast can we hammer
> without triggering TRR. My 5MHz number probably hard to achieve for
> attacker, but 2-3 MHz sound doable.

The RowHammer fix Target Row Refresh TRR is triggered when the Maximum
Activate Count MAC is reached within the Maximum Activate Window time tMAW.
It doesn't matter how opens are distributed in time within tMAW.
It looks like tMAW is the chip refresh interval of 64 ms.
When MAC is reached TRR must immediately refresh the two adjacent rows.

The problem with TRR is that the controller (presumably) reads the
MAC and tMAW values from the DRAM configuration registers.
However RowPress shows that holding a row open greatly lowers the MAC
trigger level, bypassing the TRR fix.

Also as Blaster shows, TRR refreshing the two adjacent rows is not enough.
It would need to refresh +-4 rows, and that would also further divide
the MAC trigger limit by 8.

>>> The right measure is reciprocal of the total duration of attack.
>>> At any given duty cycle reciprocal of the total duration of attack
>>> grows with increased rate of interruptions (a.k.a. hammering rate).
>>> The general trend is the same as for all other RH variants, the only
>>> difference that dependency on hammering rate is somewhat weaker.
>>>
>>> Relatively weak influence of duty cycle itself is shown in figure
>>> 22.
>> Looking at figure 22 on the arxiv version of the paper,
>> this is a completely different test. This test was to explain the
>> discrepancy between the RowPress results and the earlier cited papers.
>>
>> BER is the fraction of DRAM cells in a DRAM row that experience
>> bitflips. Its a different measure because RowPress detects when ANY
>> data loss begins, not the fraction of lost data bits (efficiency)
>> after it kicks in.
>>
>> Obsv 16 explains it, the BER for the bottom two lines,
>> which are the ones with a long total tA2A, goes up in all graphs
>> by between a factor of 10 to about 500, which is the RowPress effect.
>>
>> To my eye what this test shows is the PRE phase may *heal* some of the
>> damaging effects that the ACT phase causes, but only to a certain
>> point. Possibly the PRE phase scavenges the ACT hot injection
>> carriers.
>>
>>> The practical significance of RowPress is due to two factors.
>>> (1) is the factor is the one you mentioned above - it can flip
>>> different bits from those flippable by other RH variants.
>>> (2) is that it is not affected at all by DDR4 TRR
>>> attempt of mitigation.
>> I take away something completely different: there are multiple
>> interacting error mechanisms at work here. RowHammer and RowPress are
>> likely completely different physics and fixing one won't fix the
>> other.
>>
>
> Different like coupling in different frequency bands - yes.
> But both caused by insufficient isolation.

I'm just guessing, based on the reports that different bits are affected
for RH and RP, and that RH flips 0's to 1's while RP flips 1's to 0's.
But I don't think they have had time to look at the details for RP yet.

>> It also suggests there may be other similar mechanisms waiting to be
>> found.
>>
>>> The third, less important factor is that RowPress appears quite
>>> robust to differences between major manufacturers.
>>>
>>> However, one should not overlook that efficiency of RowPress attacks
>>> when measured by the most important criterion of BER per duration of
>>> attack is many times lower than earlier techniques of double-sided
>>> and multi-sided hammering.
>> For me the BER is irrelevant if it is above 0.0.
>> I want to know where the errors start which is ACmin.
>>
>
> So, call it time to first flip. The principle is the same.
> Still, MSRH causes harm faster than RP.