5 ms·

I 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 develop

I 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 ago
From 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
angry_octet 10y ago
DRAM refresh occurs regularly and automatically, think of it as signal regeneration. But this does not correct bit flips, even on ECC memory. For ECC memory systems your idea is called ECC scrub. The idea is to trigger SBE correction before more bit flips occur, turning it into an unrecoverable or undetectable error. Usually it appears in BIOS as Patrol Scrub (continuously and slowly walk through all memory, slow enough not to contend with active programs) and Demand Scrub. See also https://github.com/andikleen/mcelog https://github.com/andikleen/mcelog I've never seen a reason for Demand Scrub until now... If the kernel talked to the memory controller to map which pages were which banks it could cause a scrub specific high risk pages (e.g. the kernel as you say) or after X uncached accesses... Or it might be possible to segregate less trusted code to specific bank groups. https://lackingrhoticity.blogspot.com/2015/05/how-physical-addresses-map-to-rows-and-banks.html https://lackingrhoticity.blogspot.com/2015/05/how-physical-a... Another approach might be to use memory integrity. Intel SGX has memory encryption and uses a tree of hashes to validate. It has holes against an on-machine attacker, but would defend against bit flips. https://eprint.iacr.org/2016/204.pdf https://eprint.iacr.org/2016/204.pdf

ecma 10y ago

From 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

angry_octet 10y ago

DRAM refresh occurs regularly and automatically, think of it as signal regeneration. But this does not correct bit flips, even on ECC memory. For ECC memory systems your idea is called ECC scrub. The idea is to trigger SBE correction before more bit flips occur, turning it into an unrecoverable or undetectable error. Usually it appears in BIOS as Patrol Scrub (continuously and slowly walk through all memory, slow enough not to contend with active programs) and Demand Scrub. See also https://github.com/andikleen/mcelog https://github.com/andikleen/mcelog I've never seen a reason for Demand Scrub until now... If the kernel talked to the memory controller to map which pages were which banks it could cause a scrub specific high risk pages (e.g. the kernel as you say) or after X uncached accesses... Or it might be possible to segregate less trusted code to specific bank groups. https://lackingrhoticity.blogspot.com/2015/05/how-physical-addresses-map-to-rows-and-banks.html https://lackingrhoticity.blogspot.com/2015/05/how-physical-a... Another approach might be to use memory integrity. Intel SGX has memory encryption and uses a tree of hashes to validate. It has holes against an on-machine attacker, but would defend against bit flips. https://eprint.iacr.org/2016/204.pdf https://eprint.iacr.org/2016/204.pdf