Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena
1–10 of 49 posts
Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena
#2It'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.
Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena
#3It'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
I was shocked to learn that around 10% of Firefox crashes are caused by bit flips.
Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena
#4It'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 how DRAM works. It's frankly a miracle it works in the first place.
Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena
#5It'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
I was shocked to learn that around 10% of Firefox crashes are caused by bit flips. https://news.ycombinator.com/item?id=47252971
Most software is like this. Factorio had a weird one where some routers dropped UDP packets with zero checksum.
Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena
#6It'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…
No. If it was designed really well, it would trigger extra refreshes as needed. It would know how much accessing a row disturbs nearby rows and how much disturbance a row can suffer before it needs a refresh to prevent data corruption. It would know how long a row can be held open for, too. There is no fundamental theorem that rowhammer must work. It was an engineering tradeoff.
I don't think we can blame DRAM designers for flying a teensy bit too close to the sun here, since this is no problem in normal operation and only appears under adversarial scenarios. We can blame them for not fixing it once it was discovered. And we can definitely blame Intel for making ECC RAM a market segmentation feature.
Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena
#7It'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.
Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena
#8Earlier 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…
No. If it was designed really well, it would trigger extra refreshes as needed. It would know how much accessing a row disturbs nearby rows and how much disturbance a row can suffer before it needs a refresh to prevent data corruption. It would know how long a row can be held open for, too. There is no fundamental theorem that rowhammer must work. It was an engineering tradeoff. I don't think we can blame DRAM design…
What you describe is the Target Row Refresh (TRR) mitigation, and it can be bypassed via "half-double" attack.
Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena
#9Earlier quoted context omitted.
No. If it was designed really well, it would trigger extra refreshes as needed. It would know how much accessing a row disturbs nearby rows and how much disturbance a row can suffer before it needs a refresh to prevent data corruption. It would know how long a row can be held open for, too. There is no fundamental theorem that rowhammer must work. It was an engineering tradeoff. I don't think we can blame DRAM design…
What you describe is the Target Row Refresh (TRR) mitigation, and it can be bypassed via "half-double" attack.
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.
Re: Demystifying DRAM Read Disturbance: RowHammer and RowPress Phenomena
#10Earlier quoted context omitted.
What you describe is the Target Row Refresh (TRR) mitigation, and it can be bypassed via "half-double" attack.
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.