|
|
|
|
|
|
by bell-cot
17 hours ago
|
|
|
> 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. |
|
|
I don't know if it's doable with the current ABI between the memory controller and the memory chips, without adding a bunch of expensive static memory to the controller. It may require a protocol change. Possibly just another wire to signal back to the controller that excessive charge leakage was detected and it needs to do an early full refresh, but even that means basically a new generation of RAM.
I'm thinking that either each memory chip gains a few bits per row to store predicted charge leakage (or an actual extra bit designed to leak faster than the main bits, coupled to a detector) or the memory controller would need an array of memory for the maximum supported number of rows. Either one is possible, but a design headache.