3 ms·
Intel MEE addressed this (https://eprint.iacr.org/2016/204.pdf https://eprint.iacr.org/2016/204.pdf), by treating DRAM as entirely untrusted (assuming an attack
by Retr0id 3mo ago
Intel MEE addressed this (https://eprint.iacr.org/2016/204.pdf 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.
- inigyou 3mo agoNo. 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.
- Retr0id 3mo agoWhat you describe is the Target Row Refresh (TRR) mitigation, and it can be bypassed via "half-double" attack.
- inigyou 3mo agoWhere 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.
- Retr0id 3mo agoIt 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.
- inigyou 3mo agoOkay 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.
- deleted 3mo ago[deleted]
- reliabilityguy 3mo ago> 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
- simoncion 3mo ago> At the end you have DRAM that you cannot read from or write to at all because it’s always refreshes itself. Be so kind as to run the math on this for me? There must be something that I'm missing, because it looks like you're describing a system in which a refresh causes so much disturbance that another refresh is immediately required. Such a system seems incapable of reliably storing a byte and reading it back. The colloquial term for such a system is "unreliable garbage".
- anon_rh_guy 3mo agoLittle known fun fact: the MEE's checksum updates... were one of the most successful Rowhammer patterns... :-p
- Retr0id 3mo agoInteresting - but presumably used to attack rows outside of SGX?
- anon_rh_guy 3mo agoboth, inside and outside