21–30 of 49 posts
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
Every system fails eventually.
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.
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 Google Fiber so much as credibly threatened to start providing service in an area served by a mono/duo/triopoly. Or -more recently- how SpaceX demonstrated that the defense-contractor-owned space launch companies had spend decades wasting enormous amounts of taxpayer money by refusing to do any significant amount of research into bringing the cost to launch down substantially. ISPs and the space launch companies had no peers that would spend the resources required to provide a better and/or cheaper service to their customers, so it made absolutely no sense for any one of them to spend resources to break the truce and make them all far less money in the long run.
Earlier quoted context omitted.
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 wh…
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".
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.
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.
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 very obvious crashes all the time.
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 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.
Earlier quoted context omitted.
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…
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
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.
> 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…
Earlier quoted context omitted.
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…
Alternatively you would also count the refresh as a hammer on its adjacent rows.