How can I protect my home/office computer against row hammer?

Question

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.

Answer 1

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. Furthermore, it seems that most modern TRR implementations are ineffective and actually make the situation worse. 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. Note that you should also enable a shorter patrol scrub interval in order to prevent bitflips from becoming undetectable and, if possible, have the system panic if any error occurs, corrected or not. Make sure the scrub occurs unconditionally and is not suppressed when the system is not idle.

• 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. You would need to use a variety of rowhammer techniques to find the best patterns.

• 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). This can't be done within a single kernel without a patch.

• Use a CPU older than Skylake^* - Intel Skylake and newer CPUs support a highly-optimized version of the clflush instruction called clflushopt. This new instruction can be used to greatly enhance the efficiency of rowhammer, even in JavaScript. Unfortunately, because these instructions are always unprivileged (they work in CPL3), do not touch the microcode sequencer, and cannot be made to cause a #VMExit in a hypervisor, they cannot be disabled. The best thing to do then would be minimize the risk by using a slightly older CPU. Note that this is a serious tradeoff because newer CPUs may have rowhammer mitigations.

• Use a DRAM vendor which is less vulnerable^* - There are only three DRAM vendors. All other vendor names use one of these three. They are Micron, SK Hynix, and Samsung. Although most researchers anonymize the name of the vendors, it is very clear that one of them is far less vulnerable than the others. Don't quote me on this, but I'm pretty sure it's Samsung...

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