Hacker News new | past | comments | ask | show | jobs | submit login

Problem: They propose a solution and calculate the reliability of the solution. Why not test it with their FPGA based memory controller and demonstrate an improvement?

Second: While the problem looks real enough, the tests to demonstrate it are not realistic. Hammering the same rows with consecutive reads does not happen in the real world due to caches which the get around via flushes. I'd like to see more data on how bad the abuse needs to be to cause the problem. Will 2 reads in a row cause errors? 5? 10? 100? They never address how likely this is to be a real-world problem. I don't doubt that it is, but how often?

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.

Sometimes 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.

Multi-threaded code does not need cache flushes / invalidating reads to work correctly, on any halfway modern architecture that includes a hardware cache coherence protocol.

Reading the same address in an infinite loop is quite common in the multi-die/core real time low latency systems. In fact this is exactly what you are doing - when reading the FIFO queue pointers, etc. And rather than relying on QPI/cache coherency, you may even want to forcefully flush the cache every time you read, to reduce the latency.....

This kind of thing may not happen often but when it does it can cause errors which are very intermittent and impossible to diagnose. I have seen memory chips that will fail consistently, but only when running a specific program out of dozens of others tried. So it kind of looked like the program had a problem, except that it worked on other hardware.

It's quite easy to bypass cache without explicit flush. Most caches are 4-way or 8-way: just hit 4 or 8 addresses sharing the same cache line, and you got your original data evicted from cache.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact