Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena

arxiv.org

Post reply on HN
Print view View original

31–40 of 49 posts

Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena

#31

Post by bell-cot »

inigyou wrote: post #30
bell-cot wrote: post #17

Earlier quoted context omitted.

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…

Which is the whole chip, because if you only refresh any limited number of rows, the next row outside that range becomes a viable indirect target as shown by Half-Double. Alternatively you would also count the refresh as a hammer on its adjacent rows.

> Which is the whole chip, because ...

Here's the actual Half-Double paper:

https://www.usenix.org/system/files/sec22-kogler-half-double...

Note two things:

- The entire chip is already refreshed every 32ms to 64ms, because the capacitors which implement DRAM lose their charges over time.

- The time required to induce an exploitable bit flip is (in one system tested) was ~22ms

So: Even if it was the whole chip - vs., say, the 6 nearest rows to the highly-accessed row - the more-frequent refreshes would not be a big deal.

> Alternatively you would also count the refresh ...

Sure. Or once any row access counter triggers a refresh, extend that to every row with a row access counter within (say) 25 of its limit. And if that ends up refreshing more than (say) 25% of the chip, then just refresh the entire chip.

Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena

#32

Post by adrian_b »

reliabilityguy wrote: post #21
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

> It's my long standing opinion[1] that we shouldn't accept any RAM that can be subject to random bit flips. Every system fails eventually.

That is why every subsystem must have means to detect the failures, to allow the replacement of the bad components.

ECC in DIMMs achieves this.

For myself, this has been the greatest advantage of always using ECC, that I have been warned early about the great increase in the frequency of errors in some DIMMs, after many years (over 5 years) of continuous usage, which has allowed me to replace the offending DIMMs and continue to use those systems for some more years.

Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena

#33

Post by simoncion »

inigyou wrote: post #29
simoncion wrote: post #22

Earlier quoted context omitted.

> If it was easy they'd have done it. Why? Something like 70->90% of the world's DRAM is produced by three companies that are very friendly to each other. It makes no business sense to fix problems that you know your peer companies will not fix... that's spending money that you absolutely do not have to. If the business/economic theory doesn't sway you, look way back to what happened to ISP speeds and pricing when Go…

Isn't this a memory controller concern, anyway?

I don't know. But I do strongly suspect that if rowhammer could be eliminated by a change in memory controller behavior, it would have been eliminated long ago.

Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena

#34

Post by adrian_b »

anonymous_user9 wrote: post #24
reliabilityguy wrote: post #21

Earlier quoted context omitted.

> It's my long standing opinion[1] that we shouldn't accept any RAM that can be subject to random bit flips. Every system fails eventually.

Yes things fail, but currently random bit flips are not considered a failure.

The big companies consider them a failure in their own computers, so they use appropriate memory, but they consider that "consumers" either must accept them as normal and not a failure, or pay a great overprice in comparison with what a big company pays, in order to have memory devices with error detection.

Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena

#35

Post by adrian_b »

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.

This problem has never existed with bigger DRAM cells.

At some point in time, a few generations of DRAM ago, they have reduced the dimensions so much and without discovering adequate mitigations for the problems introduced by this, that the DRAM reliability has become inadequate.

The reason why they did this was to reduce the fabrication costs. It is likely that the pressure to reduce the fabrication costs has been caused more by the desire to increase the profit margins than by the intention to enable any price reductions, because even before the recent price increases there have been around 15 years with only negligible reductions in memory prices.

By increasing the fabrication costs, it would be easy to eliminate the RowHammer problem, while still having memory prices several times lower than the current prices.

However, the vendors do not want this. They want to find some kind of mitigation that would not cause any measurable increase in the fabrication costs. Until now they have failed to do this, but it is not clear how hard they have tried.

It is very likely that their failure to find anything that works has been caused in a good part by the secrecy that is typical for nowadays.

In the earlier times of the semiconductor industry, every manufacturing problem was described in public research papers, with complete details, and usually the right solution was found by someone else and then it spread quickly in all the industry, with much less concerns about "IP" than today.

Only this openness has allowed the creation of the successful semiconductor industry and of the "Silicon Valley".

Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena

#36

Post by alightsoul »

inigyou wrote: post #7
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

My computer with a lot of ECC DDR5 sometimes catches several bitflips in a day. I know this because they are reported to dmesg and sometimes I look at dmesg. Intel decided long ago that you would need to pay more to not be subject to random bitflips. So it's an AMD system.

For those who don't know, Intel only offers ECC in server CPUs. AMD supports it on all of their current CPUs including client aka consumer ones like in laptops and desktops.

Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena

#37

Post by alightsoul »

userbinator wrote: post #26
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

100% agree. This is a pure case of defective product. Memory not behaving like memory. It's very telling that when Rowhammer first appeared, authors of popular memory testing utilities added tests for it, and then quickly hid and disabled them by default because "too much RAM would test defective". I have no idea how they were convinced to do so.

Maybe they don't want to be seen as the boy who cried wolf? Or people would think it's a lie because it would still work for web browsing?

Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena

#38

Post by execution »

userbinator wrote: post #25
inigyou wrote: post #7

Earlier quoted context omitted.

My computer with a lot of ECC DDR5 sometimes catches several bitflips in a day. I know this because they are reported to dmesg and sometimes I look at dmesg. Intel decided long ago that you would need to pay more to not be subject to random bitflips. So it's an AMD system.

My computer with a lot of ECC DDR5 sometimes catches several bitflips in a day. Replace your RAM or find what's causing this disturbance in the environment. Sooner or later you'll get a pattern the ECC won't be able to correct. Ironically if you didn't have ECC you would instantly RMA such RAM as defective because even a simple memtest would quickly discover the problem, and "several bitflips in a day" would cause ve…

Agreed, my DIY NAS with ECC DDR4 has ran for over 5 years and I have 0 ECC errors in that time.

Something must be very wrong with OP's setup. Perhaps the RAM has been overclocked too far.

Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena

#39

Post by inigyou »

execution wrote: post #38
userbinator wrote: post #25

Earlier quoted context omitted.

My computer with a lot of ECC DDR5 sometimes catches several bitflips in a day. Replace your RAM or find what's causing this disturbance in the environment. Sooner or later you'll get a pattern the ECC won't be able to correct. Ironically if you didn't have ECC you would instantly RMA such RAM as defective because even a simple memtest would quickly discover the problem, and "several bitflips in a day" would cause ve…

Agreed, my DIY NAS with ECC DDR4 has ran for over 5 years and I have 0 ECC errors in that time. Something must be very wrong with OP's setup. Perhaps the RAM has been overclocked too far.

Well that's DDR4. Apparently DDR5 was made with tighter tolerances and less safety margin, which is why many people argue ECC should be mandatory in DDR5 - it actually relies on it.

Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena

#40

Post by inigyou »

simoncion wrote: post #33
inigyou wrote: post #29

Earlier quoted context omitted.

Isn't this a memory controller concern, anyway?

I don't know. But I do strongly suspect that if rowhammer could be eliminated by a change in memory controller behavior, it would have been eliminated long ago.

The memory controller is in charge of basically everything, because this reduces the cost of the memory chips themselves. It controls refresh cycles and which row is open. If there are memory chips that add an additional self-refresh upon detecting rowhammer, it's a hack and a layering violation.

There are memory chips with a separate, limited, built-in self-refresh capability which is used during sleep mode to allow the controller to power down.

Post reply on HN