Technical blog on low-level hardware and systems topics, including DRAM address mapping, rowhammer, CPU caches, interrupts, and the Mill CPU.
HN commenters link it to explain how physical addresses map to DRAM rows and banks, which they use in rowhammer discussions.
Ok, so you are talking about rowhammer. Let me try to put this in my own words.
https://people.freebsd.org/~lstewart/articles/cpumemory.pdf
DRAM is using hardware technology that is hard. Each dram bit can be addressed by ranks, banks, chips rows and columns. Depending on stuff, you typically read/load a whole cache line from DRAM. This is nice and easy. However, AFAIU there is delay needed in the chip after reading bytes. This means a read to subsequent cache line would be slow. Therefore, there is a strong reason to lay out subsequent data far away, ideally on different chips.
So you can read cache line #0 that can be on some physical chip #A and if you read line #1 it should not be on chip #A but ideally on a "random" other physical die.
This mapping, of "physical memory address" into actually where the data is on the DDRAM, is very much a hash function. This is usually done by the CPU manufacturer I guess. See the reversing of sandy bridge algo:
https://lackingrhoticity.blogspot.com/2015/04/l3-cache-mapping-on-sandy-bridge-cpus.html
Rowhammer is an attack, where the attacker targets a single physical chip of DRAM and cause its misbehaviour due to keeping it active in unusal patterns. RowHammer is basically about reversing that hashing and exploiting the shortcuts dram manufacturers took when producing the chips.
https://blog.cloudflare.com/every-7-8us-your-computers-memory-has-a-hiccup/
But this is about DRAM. I don't know how it works in Cache, but I don't think…
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
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
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
A 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
Kernel Module Code: 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
https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_pessl.pdf
I think what they are saying is that physical addresses don't necessarily map to bytes in DRAM in the sequential order that you might expect.
Here are more details of how it actually happens: http://lackingrhoticity.blogspot.ca/2015/05/how-physical-addresses-map-to-rows-and-banks.html