Seems like ECC or similar error detecting/correcting mechanisms could be a simple fix for this issue. It'd add a small amount to the cost of a device but not a significant amount while making exploitation quite a bit harder, especially if specialized ECC dram chips using larger and older process technology which is more resistant are used.
65 plus ones
Shared publicly•View activity
View 12 previous comments
- If you have access to the performance monitoring unit, you can count the number of cache misses or cache flushes. That would help the detection.Oct 28, 2016
- I already do the detection. The problem is that I get a lot of false positives. And you cannot count on cache flushes (CLFLUSH instruction) because rowhammer also works without it.Oct 28, 2016
- there's a paper on this that might give you some hints, but basically you'd probably need to start with just cache-miss frequency as a first filter, and once you see a high frequency of cache misses (which does not in itself imply rowhammer) you'll need to start looking into where those cache misses happen in physical memory, to see if they match a pattern.
That requires precise tracing, probably you just need to do PEBS and analyze the patterns.
You might be able to narrow the first filter down by saying "lots of cache misses from the last-level cache, but not a lot of actual cachelines were evicted" (ie it was the same cachelines over and over again, rather than flushing the whole cache.
I'm not sure how to do that.
I really think the performance counter model is a purely academic exercise. It's not a realistic solution in any general sense.Oct 28, 2016
- https://iss.oy.ne.ro/ANVIL.pdf .This paper does pretty much what described above:
A kernel module implementing the algorithm can be found here: https://github.com/zaweke/rowhammer/tree/master/anvil
(Disclosure: I am one of the authors of the paper)
After detection, the kernel module reads(i.e. refreshes) rows adjacent to the ones being accessed repeatedly. Even if the approach works with a certain level of innocuous false positives, deploying this in a larger scale requires that you know the bank and row mappings for each specific CPU models and configurations you are supporting. Two excellent sources regarding these mappings:
https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_pessl.pdfOct 28, 2016
- did you look into trying to figure out the bank and row mappings by doing timing analysis? My gut feel (that I cannot back up with any actual facts or code) is that it should be possible to at least guess the DRAM layout by simply looking for timing patterns.
Admittedly, I suspect that is much easier for an attacker than a defender. But I would assume (but have not actually tried to look into it much) that you could basically time the cache misses using the time stamp counter, and figure out where the row/bank boundaries are.
It should be fairly easy to see the "accesses to the same row are faster" pattern at least in theory. Trying to make sure you avoid prefetching and various bank access pipelining might be "interesting", but using serializing instructions and timing on an otherwise idle system sounds like it should be possible.
Obviously the whole "access to physically contiguous memory and clflush" should make it rather easier, but I suspect you could also try to find the row access timing differences even in scrambled virtual memory. Once you only rely on timings to find the rows, it might just all fall out equally well anyway.Oct 29, 2016
- My colleagues have been playing with timing measurements to infer row and bank bits and we have had some success. A lot of the measurements so far were done by accessing a contiguous memory location from a bare metal program. As expected, determining rows that belong to the same bank was straightforward since the row conflicts have measurably higher latency. Like you mentioned, the prefetcher gets in the way and we got more consistent results with the prefetcher turned off in the BIOS. At some point, we might attempt a robust implementation.
The performance counters in some Intel CPUs that track the number of times each bank is accessed were quite helpful for determining the bank bits but we only found them to be available in a limited set of CPU models.Oct 29, 2016
Add a comment...