yoongu
commented
4 years ago Thanks for the update! Sounds like you guys are making good progress.
I'd start with just a single aggressor: issuing ACT + PRE to the same row over and over again. It seems like you can toggle auto-precharge, so this can be done using ACT + READ (w/ auto-precharge). The intervening READ doesn't matter at all.
Can you guys also control the refresh interval, or even turn it off? I'd set it to a very large value (e.g., 64ms -> 1sec) and repeat the experiment. Here you'll get retention errors as well, but those should be randomly distributed whereas the rowhammer errors should be concentrated around the row you're activating.
It's hard to recommend a particular data pattern, but solid (all ones or all zeros) or striped (ones/zeros in even/odd, ones/zeros in odd/even) are good bets.
The first thousand rows on a single bank sounds like a good sample population. Just make sure that you read out the entire bank when checking for errors because we don't yet know which rows are adjacent to what.
jedrzejboczar
mithro
esshiu
kgugala
sqazi
I prepared a basic setup for running a Row Hammer attack using EtherBone to fill/check the memory and a simple DMA reader module. I did several tests on the Arty A7 board but was not able to induce any errors in the memory.
Testing procedure
The attack procedure is as follows:
address0=address(row=row0, col=512)andaddress1=address(row=row1, col=512)and run alternating DMA reads from these addresses.The pattern, the number of rows, the number of row toggles per rows pair and the choice of row pairs were being changed in different test cases.
Test cases
The initial tests were being run on 1024 rows, attacked in pairs (2n, 2n+1), so (0,1), (2,3), (4,5), ... The pattern used for filling the rows was just 0x55555555, so alternating 1s and 0s in a single row. For each pair there were ~10M row toggles.
Later I did some tests with similar number of rows with the following modifications (added one by one):
Finally I ran longer tests on all 16384 rows of the DRAM chip and ~1.5M row toggles per rows pair (took slightly over 1h per run):
For none of the tests I could identify any error.
I also verified that the reading procedure actually identifies errors by flipping a single bit manually.
Verification in simulation
To verify the correctness of our system I have run it with a simulation model of DRAM in Verilator. I was able to see correct command sequences in waveform dumps. Then I configured the model to log each DFI command that is being sent, printing time/bank/row/column/etc. I prepared a wrapper script that parses all the information and calculates the performance of our DMA reads.
In our setup we run at DDR3-800, with a refresh period of tREF=64ms and refresh command interval of tREFI=64ms/8192. The wrapper script counts the number of row toggles (i.e. of ACT commands) between two REF commands. From my tests we have a median of 93 row toggles between two subsequent REF commands. This gives 764k toggles per tREF, so before that particular row is being refreshed. Following, we have 11.9M toggles per second, which is in the range of frequencies that have been used in "4. Real System Demonstration" of the paper (11.6M, 11.7M, 12.3M and 6.1M).
Side notes
We are currently doing the tests on a single bank. The Row Hammer module could be extended to support attacking all banks at once, which should slightly increase the performance.
During the tests I was able to measure the speed at which we can currently write/read the DRAM memory over EtherBone. From my tests reading 1MB takes ~22 seconds, so reading the whole memory (256MB) should take ~1.5h. Writing is several times faster.
As for the time taken by the above tests on 16384 rows, we were using only 1 bank our of 8, so reading should take 0.1875h, which I measured and it did. Then each attack with ~1.5M toggles took ~0.16 seconds (1.5M/11.9M ~= 0.13s, so a bit of overhead there). Multiplying 0.16s*16833 = 0.728h. So adding everything together (with ~1min of writing) we have around 1h 10min.
Are there any obvious mistakes in the testing methodology used? Do we need better performance or different access patterns? Or is it possible that the DRAM chip we use (MT41K128M16) is not vulnerable?