With 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.
Are 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.
This is called Data Scrambling on Intel processors. There's not a lot of info I can find from the horse's mouth, but the datasheet [1] has a blurb:
The memory controller incorporates a DDR3 Data Scrambling
feature to minimize the impact of excessive di/dt on
the platform DDR3 VRs due to successive 1s and 0s on
the data bus. Past experience has demonstrated that
traffic on the data bus is not random and can have
energy concentrated at specific spectral harmonics
creating high di/dt that is generally limited by data
patterns that excite resonance between the package
inductance and on-die capacitances. As a result, the
memory controller uses a data scrambling feature to
create pseudo-random patterns on the DDR3 data bus to
reduce the impact of any excessive di/dt.
So basically, all the kernel knows is that the data is in there "somewhere", and can be accessed traditionally.
That seems to be exclusively about the data bus, not the address bus. So it affects what bit patterns get stored, but has no effect on where they get stored.
No, 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.
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.
dmidecode seems to indicate that the description from the actual RAM is lacking transparency about it's internal geometry.
I can get the ranking for slot-level interleaving from dmidecode on my systems (which means a kernel could or already has it as well).
Thinking about the inside-chip geometry issue as well as the current on-list proposal in the news item I've reached a different potential solution.
If page faults are tracked /by process/, the top N faulting processes could be put in to a mode where the following happens on a page fault:
* Some semi-random process (theoretically not discover-able or predictable by user processes) picks a number between 1 and some limit (say 16).
* The faulting page, and the next N pages, are read in (which should pull them in to the cache).
This would help by making it harder to mount a /successive/ attack on different memory locations. Processes chewing through large arrays of objects in memory legitimately shouldn't be impacted that much by such a solution; surely less so than a hard pause on the process.
Are you potentially confusing a page fault which results in the page being pulled into main memory with a cache miss which pulls a line from memory into on-CPU memory? My understanding is that the cache miss is managed by the MMU without much kernel involvement and we're relying on non task aware PMU statistics local to a single CPU for the proposed mitigation.
Am I missing some aspect of page mapping/cache management?
Calling that "scrambling" is pretty unhelpful, though. It's interleaving accesses across the whole collection of memory devices in a fairly regular pattern, but the mapping isn't trivial because the different levels of parallelism have different latency overheads.
If the exploit code can do it, why can't the kernel? Rowhammer is only possible because the non privileged code can predict which rows get affected, so surely the kernel can also?
