6

Row hammer seems to affect ECC memory less, but ECC is still not immune. I have heard of software mitigations like ANVIL, but that doesn't seem to be 100% row-hammer-proof either.

What software or hardware can reliably protect me against row-hammer attacks?

I have found one hint, that certain types of DDR4 memory have built-in protections that work reliably against bit flips and should thus protect against row hammer. But I'm not entirely sure I fully understand it, nor how reliable this protection should be. Would this be a reliable form of protection? A quotation:

In addition to purchasing a fast Intel Skylake based system, we also acquired four Crucial Ballistix Sport 2400 MHz, two Crucial Ballistix Elite 2666 MHZ, two Geil Super Luce 2400 MHz, two G.Skill Ripjaws 4 3200 MHz, and two Micron branded 2133 MHz DDR4 memory modules for testing… Of the twelve memory modules we tested, eight showed bit flips during our 4-hour experiment. And of these eight failures, every memory module that failed at default settings was on DDR4 silicon manufactured by Micron. The Geil branded modules contained SK Hynix and the G.Skill modules contained Samsung silicon.

Edit: in the other question, it is mentioned that Micron has built in special protections in its DDR4 chips. But I believe Samsung and SK Hynix have done that as well, and, apparently (see above), Micron's protections weren't enough.

enter image description here

  • From Wikipedia: "This circumvention of the isolation between DRAM memory cells results from the high cell density in modern DRAM" So how about using less dense memory chips? Of course, that comes with its own set of problems. – a CVn Apr 16 '16 at 21:05
  • @MichaelKjörling: Good point: maybe old RAM is immune. But, as you suggest, who wants to build a computer with old parts? Maybe you could use an old computer for certain super-sensitive work. But, if it requires lots of computing power... – Cerberus Apr 16 '16 at 23:45
  • Same Q as security.stackexchange.com/questions/96488/… -- but the only concrete answer there suggests Micron is good. – dave_thompson_085 Apr 17 '16 at 4:51
  • @dave_thompson_085: Ah, yes, I saw that question, but my question is more general ("what hardware or software...?"), as recommended in chat. And the other question and its answers were posted a year ago; the information offered is unfortunately out of date. – Cerberus Apr 17 '16 at 13:10
5

The only reliable hardware mitigation that does not involve downgrading to a motherboard with DDR2 is to use memory that supports TRR (Target Row Refresh), which is optional for LPDDR4 (not the same as DDR4). Unfortunately, many DDR4 modules do not support TRR, and there is often no easy way to tell if it is supported without digging deep. There is also pTRR (Pseudo-TRR) for DDR3 which some Ivy Bridge processors have. It requires using pTRR-compatible DIMMs. I do not know how effective or reliable this is as there is little information available on its implementation or specifications available online. Other than that, there are a few techniques to reduce susceptibility:

  • Use ECC and panic on MCE - While ECC does not fully mitigate the attack, if you configure the computer to panic on any violations (called Machine Check Exceptions, or MCEs), it can go a long way. An attacker will have a much harder time successfully exploiting the system if the first detected error results in the system halting. High scrub rates improve detection.

  • Increase refresh rates* - By default, memory is refreshed at 64ms intervals. Some BIOSes allow you to specify the refresh interval. Reducing this to 32ms makes rowhammer more difficult to exploit, at the expense of performance and energy usage. Reducing it even further helps more, but with an even higher performance impact. Some BIOS vendors that claim to have a rowhammer mitigation setting (either optional or enabled by default) simply reduce the refresh interval to 32ms.

  • Reduce clock speed* - Reducing the maximum clock speed of every core makes it more difficult to access rows of memory at a high rate, as memory access is naturally bounded by clock speed. This mitigation only works for memory that is borderline vulnerable, and at a high price (significantly reduced performance). You can also disable Hyper Threading or other forms of SMT and switch to using a single core, again resulting in a significant performance impact.

  • Set CPU and RAM resource limits* - Rowhammer requires hammering memory which uses up a lot of CPU time. Some privesc attacks additionally work more quickly if the malicious process can allocate a lot of memory. Setting strict resource limits to kill a process that uses too much CPU or memory can slow down attacks when using memory modules that are borderline vulnerable.

  • Disable JIT in web browsers - JIT, or Just-in-Time compilation, is an optimization feature used by browsers which compiles JavaScript into executable code. This greatly speeds up heavy scripts on webpages. However, it also makes rowhammer from the browser possible. Disabling JIT reduces JavaScript performance enough that this attack becomes infeasible. Note that this mitigation only reduces susceptibility of the browser, not any other local processes!

  • Use memory with a high MAC - The Maximum Activation Count, or MAC, is a measure for DRAM that counts how many accesses can occur to a row within a single refresh interval before instability results. A higher MAC is better, and an unlimited MAC is ideal. Modules with an unlimited MAC are, in theory, not vulnerable to rowhammer. You will need to search the datasheets in order to find out the MAC for that particular model, or obtain the data via SPD. It would also be necessary to test the modules to make sure they are safe, as the reported MAC value is not always accurate.

  • Blacklist vulnerable addresses - A special feature of x86 CPUs is e820, which contains a list of physical memory addresses that the CPU will hide and refuse to map to virtual memory. Combine this with the fact that rowhammer typically affects the same rows over and over (i.e. there are susceptible rows and there are insusceptible rows in any given module), it makes sense to find these vulnerable addresses and blacklist them. This is the approach taken by B-CATT.

  • Physically partition memory - If you can partition your memory such that processes of different security levels are never mapped to adjacent rows, you can isolate rowhammer-based corruption. This can be useful when allocating memory for virtual machines, or when segmenting memory so there is a split between user and kernel physical memory regions (not just the "upper" kernel).

Many rowhammer-related questions and discussions are present on rowhammer-discuss.

* On their own, these mitigations can do very little and only slightly reduce the rate of bitflips in many circumstances.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.