Hacker News Reader

Comment by Sanddancer | Hacker News Reader

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.

View on HN

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.

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.

What 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.

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-add...

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.

I see where you're going with this.

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?

If you want a bit more info about the scrambling process, see:

https://www.usenix.org/conference/usenixsecurity16/technical...

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.

[1] http://www.intel.com/content/dam/www/public/us/en/documents/...

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.

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?

Reply on news.ycombinator.com