4 ms·
They address all of these in the paper. It takes ~180,000 "hammered" reads to trigger. The problem is even the least-privileged code can do it because it's just
by xenadu02 12y ago
They address all of these in the paper. It takes ~180,000 "hammered" reads to trigger. The problem is even the least-privileged code can do it because it's just reading without using the cache - a perfectly valid thing that must be allowed for multi-threaded code to even work correctly.
Secondly, the DRAM makers don't currently provide enough information to reliably know what neighbors to refresh. I suppose they could have used their guesses to test on the FPGA rig but given the rest of the paper I'm reasonably satisfied that they have correctly identified the problem and that their solution would work.
- kabdib 12y agoSometimes an exploit simply needs to make more trusted code take an exception (often after "paving" memory with known values). Since an exception can be theoretically be induced by user-mode code flipping bits in structures it doesn't own . . . I can see "exploit resistant memory" being a selling point, maybe soon.
- caf 12y agoMulti-threaded code does not need cache flushes / invalidating reads to work correctly, on any halfway modern architecture that includes a hardware cache coherence protocol.