12 ms·
Defending against Rowhammer in the Linux kernel
- partycoder 10y agoFlagged for linking subscriber only material.
- CalChris 10y agoThe actual content was in fact made available by a subscriber.
- edmccard 10y agoFTA: "The following subscription-only content has been made available to you by an LWN subscriber." Was that not there 15 minutes ago?
- partycoder 10y agoBy saying "subscriber only content shared by a subscriber", made me think it could be a subscriber-to-subscriber thing. But well, someone else cited how this assumption was wrong. They should phrase it in a less ambiguous way.
- detaro 10y agohttps://lwn.net/op/FAQ.lwn https://lwn.net/op/FAQ.lwn: Where is it appropriate to post a subscriber link? Almost anywhere. Private mail, messages to project mailing lists, and blog entries are all appropriate. As long as people do not use subscriber links as a way to defeat our attempts to gain subscribers, we are happy to see them shared.
- partycoder 10y agoOk then, unflagged. Thanks for the clarification.
- wtallis 10y agoLWN's editor has repeatedly said he doesn't mind the occasional subscriber link being posted here.
- mjevans 10y agoWouldn't an effective countermeasure to this also be knowing what types of neighboring cell reads are vulnerable and forcing reads on those instead? Bonus points if the reads pull in to the cache data that is actually useful to sequential access.
- Sanddancer 10y agoWith modern processors, that becomes a much more difficult proposition. For various reasons, processors now scramble addresses before writing to dram. This makes it more difficult to figure out which cells are neighboring, and much more difficult to implement that type of countermeasure.
- mjevans 10y agoAre you talking about userspace memory mapping (via pagetables) to physical address space, getting confused about what Address Space Layout Randomization does, or thinking of the very latest CPUs (announced) which offer to encrypt the content of memory pages (Secure Memory Encryption and Secure Encrypted Virtualization)? In any event, the kernel can know what's behind the curtain and that is the context in which the suggestion and news item exist.
- makomk 10y agoNo, the physical addresses used by the kernel and other devices are scrambled before they're used to access DRAM on modern hardware. This is not visible to the kernel.
- mjevans 10y agoWhat is the specific feature called? It //STILL// sounds like something that happens in the MMU, at the time that the virtual address is mapped back to physical addresses via the page tables; which means that the kernel still knows the real backing addresses.
- 10y ago
- CalChris 10y agoThis approach was also covered at Black Hat: https://www.youtube.com/watch?v=dfIoKgw65I0 https://www.youtube.com/watch?v=dfIoKgw65I0 https://www.blackhat.com/docs/us-15/materials/us-15-Herath-These-Are-Not-Your-Grand-Daddys-CPU-Performance-Counters-CPU-Hardware-Performance-Counters-For-Security.pdf https://www.blackhat.com/docs/us-15/materials/us-15-Herath-T...
- ta161028 10y agoIf you know how memory addresses map to row/column, it should be possible to force refresh the entire array with a few tens of thousands of reads, rather than delaying for 64ms. (At least on conventional DRAM, reading a row implicitly refreshes it; I presume it's the same on DDR SDRAM.)
- PhantomGremlin 10y agoYes, I just posted this in somewhat greater detail. https://news.ycombinator.com/item?id=12821946 https://news.ycombinator.com/item?id=12821946 There are a lot of details to consider. E.g. reading DRAM (rather than from on-chip cache) consumes a lot more power, which could be quite harmful on a laptop.
- salessawi 10y agoA very similar approach, that attempts to refresh rows adjacent to the ones that are being repeatedly accessed is described here(disclosure: I am one of the authors of the paper): Paper: https://iss.oy.ne.ro/ANVIL.pdf https://iss.oy.ne.ro/ANVIL.pdf Kernel Module Code: https://github.com/zaweke/rowhammer/tree/master/anvil https://github.com/zaweke/rowhammer/tree/master/anvil It is tested on on an Intel SandyBridge CPU. For a full deployment, we would need to know which bits of the physical address are used to select the DRAM banks and rows for each specific CPU. There has been some effort to reverse engineer these mappings by various people. Two excellent sources regarding these mappings: http://lackingrhoticity.blogspot.com/2015/05/how-physical-addresses-map-to-rows-and-banks.html http://lackingrhoticity.blogspot.com/2015/05/how-physical-ad... https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_pessl.pdf https://www.usenix.org/system/files/conference/usenixsecurit...
- antocv 10y agoThis, this is the real golden solution. Thank you for your work and links, so full of information, golden, golden!
- PhantomGremlin 10y agoI have an alternative suggestion for how to mitigate this. I designed a number of DRAM memory boards "back in the day", but haven't kept up with recent developments. But this idea could be used as a starting point by someone more in tune with current hardware to write a kernel module to help mitigate Rowhammer. One key thing to know is that, internally, a DRAM chip isn't accessed by a single row (of let's say 32 bits) at a time. What happens is that a read causes a large number of bits (literally thousands) to be accessed and refreshed at once. Then the selected 32 bits are returned to the CPU. But, as a side effect, all those 1024 bits (or perhaps a lot more in current DRAM chips) are refreshed. So what's needed is a background process that does the following for all of physical memory: perform an uncacheable read of 32 bits direct from DRAM increment read address by perhaps 32 words pause for some small amount of time (perhaps 1 usec) repeat forever This task of repeatedly sweeping through physical memory will, as a side effect, cause all memory cells to be refreshed. Obviously there is some magic needed, which can only be done in the kernel. First, all of physical memory must be able to be accessed by this process. Second, some tuning must be done to keep the task from consuming too much memory bandwidth. Third, it might make more sense to do something like reading quickly a burst from 4 different physical memory locations then pausing for 4x as long. Unfortunately, running this type of program would be devastating in terms of power consumption. DRAM chips consume much more power while being accessed than while they are in standby. So it probably would have an large deleterious effect on a laptop. But it would probably be OK on a desktop or server. That just the basic idea. There is a lot of tuning that could be done. For example, instead of reading thru all of physical memory, perhaps just read only the kernel memory. That's a lot less memory, a lot lower power consumption. The idea is that corrupted kernel memory is potentially a lot more harmful than corrupted memory used by some random user process.
- ecma 10y agoFrom the Wikipedia article on memory refresh [0] for DRAM describing distributed refresh techniques: "For example, the current generation of chips (DDR SDRAM) has a refresh time of 64 ms and 8,192 rows, so the refresh cycle interval is 7.8 μs." Sounds like your idea is already a thing! That's cool! Unfortunately it seems like the performance-cycle period tradeoff is difficult and Rowhammer is taking advantage of that. Protecting subsets of memory is an interesting idea but what bits do you choose? What if I could Rowhammer the memory frame behind a COW page belonging to a setuid binary? I feel like it might be an all or nothing kind of thing in this situation. Who knows though, maybe there's merit in specifically protecting kernel owned frames, it's difficult to say for sure. 0 - https://en.m.wikipedia.org/wiki/Memory_refresh https://en.m.wikipedia.org/wiki/Memory_refresh
- yyhhsj0521 10y agoJust curious, is it possible to rowhammer cache?
- cesarb 10y agoCache is usually SRAM, while rowhammer is a problem specific to DRAM.
- Zenst 10y agoA nice relevent discussion from a post Alan Cox started upon G+ recently https://plus.google.com/u/0/+AlanCoxLinux/posts/AFqqpTPpKZ5 https://plus.google.com/u/0/+AlanCoxLinux/posts/AFqqpTPpKZ5 Lunus covers the TL;DR in this quote "there is nothing remotely sane you can do in software to actually fix this." and gets down to ECC memory being the golden solution.
- ryuuchin 10y agoECC isn't really the golden solution. It will likely just turn rowhammer into a DoS instead of something which is exploitable (and even with ECC it can still be exploitable just harder). While this is an improvement I wouldn't call it a golden solution.
- Zenst 10y agoYour right, my bad and it is more case of it being the best solution to date.
- ta161028 10y agoIf you can change the hardware then the best solution is TRR, which should completely eliminate bit flips due to rowhammer. This doesn't do anything for the millions(?) of vulnerable systems in the wild.
- snuxoll 10y ago
- Marat_Dukhan 10y agoI don't see how it will help. First, if the vendors can ship a new Linux kernel, they can as well ship updated firmware to increase memory refresh frequency. Secondly, on mobile devices CPU and GPU share the same memory, and it could be only a matter of time before we see GPU-powered rowhammer attack.
- angry_octet 10y agoWhy do you think the firmware would be capable of programming DRAM refresh rate to a heretofore unheard of frequency? This capability does not exist in the memory controller. It might be hard to get the GPU to hammer memory hard enough because of the caches (http://wccftech.com/intel-skylake-gen9-graphics-architecture-explained-gt2-24-eus-gt3-48-eus-gt4e-72-eus/ http://wccftech.com/intel-skylake-gen9-graphics-architecture...). Maybe with glBufferData in DRAW mode it would force uncached access, depends if the graphics core cache snoops the address bus (coherent) or not, in which case it could be tricked. However the AMD Fusion docs certainly seem to indicate it is possible, and significantly higher read bandwidth than from the CPU (http://developer.amd.com/wordpress/media/2013/06/1004_final.pdf http://developer.amd.com/wordpress/media/2013/06/1004_final....). Indeed, it makes me wonder why (given the repetitive read pattern required for updating VBOs) whether the system instability people have seen before is not due to the GPU doing unintentional rowhammer.
- Marat_Dukhan 10y agoI thought refresh rate is programmable. But if not, at least firmware could lower the DRAM frequency. Intel GPUs have write-back caches because they share L3 cache with CPU cores. AFAIK, other GPUs typically have write-through caches, which doesn't help against rowhammer.
- stugillibrand 10y agoI realise the article already touched on this, however issueing non temporal stores (MOVNT family) will bypass caches thus mitigating this particular proposed protection.
- salessawi 10y agoA kernel module implementation along the same line: https://news.ycombinator.com/item?id=12822490 https://news.ycombinator.com/item?id=12822490