Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena • Hacker News Board

Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena

#11

Post by inigyou » Fri, Jul 31, 2026, 10:30 PM UTC

Retr0id wrote: post #10

inigyou wrote: post #9

Earlier quoted context omitted.

Where did I imply that they should use an incorrect underestimation of row disturbance? If they actually measured these things, they'd know how far away a disturbance can be created before it becomes so weak the normal refresh cycle fixes it.

It is not feasible for DRAM (or the memory controller) to maintain a fully accurate simulation of DRAM. If it was easy they'd have done it.

Okay then refresh the whole thing and not just a single row whenever TRR is triggered.

Or refresh the whole thing after a certain number of row activations.

Or interleave activations with refreshes. Say, after every 5 activations, refresh the next row in the refresh cycle.

I'm not a DRAM expert. They can figure it out. I promise if you refresh the whole chip after every row activation you won't have rowhammer. It'll be too slow though. Somewhere in between is the fastest point where there isn't rowhammer.

Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena

#12

Post by [deleted] » Fri, Jul 31, 2026, 10:36 PM UTC

inigyou wrote: post #11

Retr0id wrote: post #10

Earlier quoted context omitted.

It is not feasible for DRAM (or the memory controller) to maintain a fully accurate simulation of DRAM. If it was easy they'd have done it.

Okay then refresh the whole thing and not just a single row whenever TRR is triggered. Or refresh the whole thing after a certain number of row activations. Or interleave activations with refreshes. Say, after every 5 activations, refresh the next row in the refresh cycle. I'm not a DRAM expert. They can figure it out. I promise if you refresh the whole chip after every row activation you won't have rowhammer. It'll…

[deleted]

Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena

#13

Post by bell-cot » Fri, Jul 31, 2026, 11:15 PM UTC

Retr0id wrote: post #10

inigyou wrote: post #9

Earlier quoted context omitted.

Where did I imply that they should use an incorrect underestimation of row disturbance? If they actually measured these things, they'd know how far away a disturbance can be created before it becomes so weak the normal refresh cycle fixes it.

It is not feasible for DRAM (or the memory controller) to maintain a fully accurate simulation of DRAM. If it was easy they'd have done it.

It doesn't need to be a fully accurate simulation, any more than your car needs a fully accurate ICE simulation to decide "Change the engine oil".

Just count accesses to each row, and refresh the adjacent row(s) when some limit is reached.

Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena

#14

Post by gpm » Fri, Jul 31, 2026, 11:21 PM UTC

Retr0id wrote: post #10

inigyou wrote: post #9

Earlier quoted context omitted.

Where did I imply that they should use an incorrect underestimation of row disturbance? If they actually measured these things, they'd know how far away a disturbance can be created before it becomes so weak the normal refresh cycle fixes it.

It is not feasible for DRAM (or the memory controller) to maintain a fully accurate simulation of DRAM. If it was easy they'd have done it.

It doesn't need to be fully accurate, merely always conservative. It's a question of cost (how much performance does the conservative estimate waste) not feasibility.

Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena

#15

Post by inigyou » Fri, Jul 31, 2026, 11:37 PM UTC

bell-cot wrote: post #13

Retr0id wrote: post #10

Earlier quoted context omitted.

It is not feasible for DRAM (or the memory controller) to maintain a fully accurate simulation of DRAM. If it was easy they'd have done it.

It doesn't need to be a fully accurate simulation, any more than your car needs a fully accurate ICE simulation to decide "Change the engine oil". Just count accesses to each row, and refresh the adjacent row(s) when some limit is reached.

Half-Double is an attack where you hammer the rows 2 spaces away so that the automatic refresh on the rows 1 space away is what actually hammers the target row.

Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena

#16

Post by anon_rh_guy » Sat, Aug 01, 2026, 12:00 AM UTC

Retr0id wrote: post #4

mikewarot wrote: post #2

It's my long standing opinion[1] that we shouldn't accept any RAM that can be subject to random bit flips. Most of the mitigations are just security through obscurity. [1] https://news.ycombinator.com/item?id=33860477

Intel MEE addressed this ( https://eprint.iacr.org/2016/204.pdf ), by treating DRAM as entirely untrusted (assuming an attacker with arbitrary physical read/write capabilities), but then they discontinued it. Regarding your linked comment: > If we had properly tested and validated RAM, RowHammer wouldn't work, ever. While it's exacerbated by physical defects and tight timings, it's really a fundamental problem with h…

Little known fun fact: the MEE's checksum updates... were one of the most successful Rowhammer patterns... :-p

Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena

#17

Post by bell-cot » Sat, Aug 01, 2026, 12:22 AM UTC

inigyou wrote: post #15

bell-cot wrote: post #13

Earlier quoted context omitted.

It doesn't need to be a fully accurate simulation, any more than your car needs a fully accurate ICE simulation to decide "Change the engine oil". Just count accesses to each row, and refresh the adjacent row(s) when some limit is reached.

Half-Double is an attack where you hammer the rows 2 spaces away so that the automatic refresh on the rows 1 space away is what actually hammers the target row.

Yes? When a given row's counter hits the limit, you refresh every other row which your actually-competent testing has shown might maybe possibly be compromised by that activity.

Same as a good car's computer doesn't make a bunch of rosy assumptions about whether the oil needs changing or not - the automotive engineers actually do their jobs, test the crap out of their engine designs, and base the oil-change criteria on the real-world test results.

(JIC: "Adjacent" has a range of meanings in English. Those go from "the singular closest neighbor, within further constraints on type, orientation, etc." to "relatively close to by some metric". But I am not an EE, let alone a chip architect, to know the "real insider" lingo here.)

Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena

#18

Post by Retr0id » Sat, Aug 01, 2026, 12:24 AM UTC

anon_rh_guy wrote: post #16

Retr0id wrote: post #4

Earlier quoted context omitted.

Intel MEE addressed this ( https://eprint.iacr.org/2016/204.pdf ), by treating DRAM as entirely untrusted (assuming an attacker with arbitrary physical read/write capabilities), but then they discontinued it. Regarding your linked comment: > If we had properly tested and validated RAM, RowHammer wouldn't work, ever. While it's exacerbated by physical defects and tight timings, it's really a fundamental problem with h…

Little known fun fact: the MEE's checksum updates... were one of the most successful Rowhammer patterns... :-p

Interesting - but presumably used to attack rows outside of SGX?

Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena

#19

Post by anon_rh_guy » Sat, Aug 01, 2026, 1:06 AM UTC

Retr0id wrote: post #18

anon_rh_guy wrote: post #16

Earlier quoted context omitted.

Little known fun fact: the MEE's checksum updates... were one of the most successful Rowhammer patterns... :-p

Interesting - but presumably used to attack rows outside of SGX?

both, inside and outside

Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena

#20

Post by reliabilityguy » Sat, Aug 01, 2026, 3:57 AM UTC

inigyou wrote: post #11

Retr0id wrote: post #10

Earlier quoted context omitted.

It is not feasible for DRAM (or the memory controller) to maintain a fully accurate simulation of DRAM. If it was easy they'd have done it.

Okay then refresh the whole thing and not just a single row whenever TRR is triggered. Or refresh the whole thing after a certain number of row activations. Or interleave activations with refreshes. Say, after every 5 activations, refresh the next row in the refresh cycle. I'm not a DRAM expert. They can figure it out. I promise if you refresh the whole chip after every row activation you won't have rowhammer. It'll…

> Okay then refresh the whole thing and not just a single row whenever TRR is triggered.

How would you refresh the whole DRAM? Refresh is simply reading the row and writing it back, it is sequential in nature.

> Or interleave activations with refreshes. Say, after every 5 activations, refresh the next row in the refresh cycle.

It makes zero sense. Refresh is disturbance in itself. You are entering a recursion here where the mere act of refreshing increases the counter values of victim rows making refresh even more frequent. At the end you have DRAM that you cannot read from or write to at all because it’s always refreshes itself.

> I'm not a DRAM expert

Yes