Rowhammer
Every account of this says the hammering has to be fast enough, and none of them says fast enough for what. Both numbers are in the paper. A row cannot be reopened faster than its row cycle time, typically 50 nanoseconds, and as few as 139,000 toggles will flip a bit in a neighbouring row. That is under seven milliseconds of work. The thing it has to beat is the refresh, which restores every row inside a window of 64 milliseconds, and that number belongs to another machine on this site rather than to this one. So the attack is not racing the refresh at all. It finishes nine times over inside the time it is given, and the last panel shows why the obvious fix, refreshing more often, costs what it costs.
New to how a row of memory is opened? Start here
The cells in this kind of memory are arranged in rows, and a cell cannot be read on its own. The whole row is opened, which drains its charges into a set of sense amplifiers, and the act of reading destroys what was there, so the row is written back as part of the same operation. Opening a row and closing it again takes a fixed minimum time, and that limit is what stops the same row being reopened arbitrarily fast.
Rows sit close together, and opening one disturbs its neighbours slightly. Do it few enough times and the disturbance is nothing. Do it often enough, before the neighbouring row's own scheduled restoration, and a bit in it can flip. That is the whole mechanism, and this page is the arithmetic of how often is often enough.
What a processor actually does
A processor fetches an instruction, works out what it says, does that one small thing, and moves to the next. Add these two numbers. Put this number there. If that number is zero, carry on somewhere else. That is the job, and it repeats a few billion times a second.
Everything that looks like cleverness is arrangement around that loop: keeping the next instruction ready before it is asked for, keeping recently used numbers close by, letting a slow part and a fast part work at once. The machines here are those arrangements, and most of them exist because one part of the machine is thousands of times slower than another.
The machine for this idea on its own is Stored Program, if you would rather press it than read about it.
Reading one address changes a different address you never wrote
1 Activations times the row cycle time, which is how long the hammering needs at best
Two numbers from the paper decide this, and no explainer puts them together. A row cannot be reopened faster than tRC, which the paper gives as typically 50 nanoseconds, and it takes as few as 139K toggles to flip a bit in a neighbouring row. Multiply, and you have how long the attack needs. The window it has to finish inside is not this page's number: it belongs to DRAM Refresh, and this page reads it from that machine rather than keeping a second copy.
| quantity | value | where it comes from |
|---|
2 What the paper measured across 129 modules, which is a census and not a model
The paper is an experiment before it is an attack. The authors built an FPGA testing platform and ran it over commodity modules bought off the shelf, and what they found is a census rather than a demonstration. These are counted parts, not a model, and nothing on this page varies them.
| population | showed disturbance errors | share |
|---|
3 The refresh interval short enough to stop it, priced by the machine that owns refreshing
If the attack finishes well inside the window, the obvious fix is to refresh more often, so that a row is restored before enough toggles accumulate. That means an interval shorter than the hammer time. What it costs is not this page's arithmetic either: the overhead is computed by DRAM Refresh's own function, with the shortened window handed to it, so the two machines cannot disagree about what refreshing costs.
| refresh window | share of the memory spent refreshing | computed by |
|---|
These ran in this browser when the page loaded. Each claim, whether it held, and the number behind it.
| claim | held | measured |
|---|---|---|
| the refresh window is read from DRAM Refresh, not typed here | yes | DramRefresh.JEDEC.windowMs is 64 ms, and this page holds no copy of it |
| 139,000 activations at 50 ns is 6.95 ms of hammering | yes | 139,000 x 50 ns, both from the paper, over 1,000,000 ns in a millisecond |
| so the attack finishes 9.2 times over inside the window, rather than racing it | yes | 6.95 ms against 64 ms |
| 110 of 129 modules and 836 of 972 chips showed errors | yes | 85.3 per cent of modules and 86.0 per cent of chips, on an FPGA test platform, not in a browser |
| refreshing often enough to stop it multiplies the refresh overhead by 9.2 | yes | 4.19 per cent at 64 ms becomes 38.60 per cent at 6.95 ms, computed by that machine's function and not a second copy |
What is real here, and what is not
No bit is flipped here, and nothing in this browser could
This page runs no attack. It has no access to memory addresses, no way to bypass a cache, and no ability to observe a disturbance error, and a page claiming otherwise would be lying about what a browser can do. What runs here is arithmetic on two figures from the paper, and a census of what its authors measured on an FPGA platform. The demonstration in the paper needed hardware this page does not have.
The thresholds are measurements of 2012 and 2013 parts, not properties of DRAM
As few as 139K activations and one susceptible cell in 1.7K are the extremes the authors found across the modules they tested, and the paper is explicit that all modules manufactured in those two years were vulnerable while older ones were not. Neither number is a constant of the technology, and both would be different on parts made before or since. The slider exists so the arithmetic can be run against any threshold rather than against one that sounds settled. The row cycle slider reaches well past any real part's 50 nanoseconds, which is deliberate: at the paper's own figures the attack always fits inside the window, so a slider that could not pass 64 milliseconds would have made the state where refreshing wins unreachable, and a page cannot show a mechanism it can never enter.
The window is DRAM Refresh's number, and if that machine is absent this page refuses to answer
The 64 millisecond retention window is stated by the DDR3 standard and is already on the roster, so this page reads it out of that machine's engine instead of writing 64 down a second time. If DRAM Refresh is not loaded, the row that needs it goes red and says so, and the race is not computed at all. That is deliberate: a page that quietly substitutes its own copy of somebody else's number is how two pages come to disagree while both look right.
The mitigation is one arithmetic consequence, not a survey of defences
Shortening the refresh interval below the hammer time is the mitigation this arithmetic reaches, and it is not the one the industry adopted. Targeted row refresh, error-correcting memory, and the probabilistic schemes the paper itself proposes all exist and none is modelled here. What this page shows is why the obvious answer is expensive, which is the same reason the others were worth designing.
A row cycle time is a floor, and real hammering is slower than the floor
tRC limits how quickly the same row can be reopened, so activations times tRC is the fastest the toggling could possibly go. Real code has to miss the cache on every access, contend with other traffic, and survive whatever the memory controller decides to reorder. The paper's own measured access rates are lower than this floor. So the hammer time here is a best case for the attacker, and the conclusion, that it finishes many times over inside the window, only gets stronger if it is slower.
Sources
- Yoongu Kim, Ross Daly, Jeremie Kim, Chris Fallin, Ji Hye Lee, Donghyuk Lee, Chris Wilkerson, Konrad Lai and Onur Mutlu, Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors, ISCA 2014. The abstract for 139K accesses and one cell in 1.7K; section 1 for 110 of 129 modules and 836 of 972 chips; section 2 for tRC at 50 nanoseconds and the 8192 refresh commands in a 64 ms window.
- Logical Art, the studio this belongs to.