Item — HN Reader

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 on the real-world test results.

(JIC: "Adjacent" has a range of meanings in English. Those go from "the singular closest neighbor, within further constraints on type, orientation, etc." to "relatively close to by some metric". But I am not an EE, let alone a chip architect, to know the "real insider" lingo here.)

2 comments

The later I get into my career the more I'm convinced that the biggest engineering challenge is to convince others there's a problem to begin with. This is also why I think innovation generally only happens in smaller companies: less convincing.

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.

Yes. Something like that would likely solve the problem entirely.

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.