Through creative application of rowhammering techniques, all the DDR4 modules they tested (which include the target-row-refresh hardware mitigations that were supposed to fix the issue once and for all) fall to Rowhammer.
We conclude that after almost a decade of research and deployed in-DRAM mitigations, we are
perhaps in a worse situation than when Rowhammer was first discovered.
Time to curl up with this paper and see just how bad it is⌠though I already know the answer.
They say ECC memory makes it harder, so thereâs some hope yet, but harder != impossible or even necessarily actually difficult, if it can be algorithmically reduced.
Iâll be interested to find out what strategies they take to try to minimize the damage from this attack. My read on it suggests that it may well be impossible to entirely mitigate, and weâll end up with a sliding scale of techniques used to hopefully reduce the success percentage rather than cut it to identical zero. How close they can get is the big question.
Attacks like this are certain to continue to evolve in sophistication. Thereâs going to be a massive installed and actively utilized base of vulnerable memory for decades yet anyway.
Yup. After chewing through it⌠âugh, computersâŚâ is still applicable.
This is a perfect example of, âAttacks only get better.â They were able to test some older rowhammer techniques (TRRespass) against their samples, and their technique went from ~35% of the DIMMs failing with TRRespass, to 100% failing with their Blacksmith tool. Literally every one. Then they took some LPDDR4 that was behaving properly, did some analysis on the TRR stuff, and figured out how to make it misbehave.
The takeaway should be that with a bit of effort, all DDR4 is vulnerable to rowhammer, the only question is âJust how bad is it?â Given that one well placed flip can compromise a system entirely⌠well⌠yeah. It sucks.
The âsolutionâ to Rowhammer in the DDR3 chips was, âOh, yeah, weâll totally use Target Row Refresh in DDR4, thatâll solve it.â If some row has been accessed enough, refresh nearby rows. Problem solved! Well⌠for trivial cases and examples, yes, but the last couple papers have been âHow to bypass TRR and still get bit flips.â This being a case. The TRR stuff just canât handle complex patterns, and the DRAM is bad enough that even with less-than-optimal hammering, you can still get plenty of useful bit flips out of the system.
Seriously, though. If you have a DDR4 based system, your system is vulnerable. Thatâs how bad this is.
ECC helps some, and the early papers said something along the lines of, âWell, yeah, you could theoretically break ECC with it, but that would be really hard, youâd have to deeply understand the system⌠eh, probably fine.â Enter bored grad students⌠and ECC falls. Itâs a lot harder to make work, but once you get the knack for a particular configuration, itâs not too hard, apparently.
âIgnore it entirely and pretend it doesnât existâ would be my bet. Respond to anyone who argues with âDamned paranoid security nerds, thisâll never work in practice,â and go on the way.
The problem is that most of the mitigations are in hardware. TRR is âin-DIMMâ mitigations, you canât just go flashing the new RAM firmware in the field. If itâs vulnerable to some pattern, itâs vulnerable, and all you can do is change the RAM out, or maybe put some software mitigations in, but they both slaughter performance and donât tend to work. Itâs ugly.
You could, sure, but howâs the actual memory controller slicing up physical addresses to DIMMs? How are the DIMMs mapping row number to physical position? Some of these are considered trade secrets (Intelâs triple channel algorithm for the first tends this way), some are simply unknowable from the interfaces provided (the second - you can sometimes work it out, but not with great detail).
Even with a lot of information provided by the system (server platforms tend to be a bit more agreeable to this if you know how to ask), itâs still far from easy to segment out physical chunks, and all that does is help if the row # to physical mapping is sane. A remapped row because one had defects can be all the way across the die from the numerically close ones, leading to potentials for attack.
On the plus side, Iâm pretty sure my ancient Atom netbook Clank wonât be vulnerable to this⌠it doesnât have the DRAM performance, nor the CPU performance, and itâs immune to speculative vulnerabilities because it doesnât speculate. Itâs also rather slower than a Rpi 4âŚ
Maybe just keep the appâs access within a single page and treat dimms like storage and abstracted accordingly? Can you rowhammer a paging file? Yeah perf drawback, but isnât the whole point of rowhammers is that you get near-native access to ram and can discover neighboring rowâs information?
âYou get one page, anything else will be abstracted like swapâ would be slower but also prevent the direct memory access that allows this style of attack.
If your goal is to emulate a 486 on modern hardware, that could do it!
Making a kernel trap for every memory access isnât feasible, and thatâs how most workloads would end up under that sort of system.
You canât generally discover a neighboring rowâs information. You can, however, corrupt it - regardless of the page access permissions. Itâs the art of writing something you canât write by reading something you can read very aggressively.
âDirect memory accessâ to memory is pretty much how modern systems work. Thereâs no easy way to replace that model and still have anything faintly performant on current system designs.
