Huge pages instead of /proc/pid/pagemap

[pewpew1...@gmail.com]

Hi!

Possibly silly questions up ahead.

I'm a student looking into rowhammer and have ran into some troubles when trying to implement it without access to /proc/pid/pagemap since userspace processes are no longer allowed read access to /proc/pid/pagemap.

In the original blogpost, it was mentioned that

The relative physical addresses of memory we have access to. Linux can allow this via its support for “huge pages”, which cover 2MB of contiguous physical address space per page. Whereas a normal 4k page is smaller than a typical DRAM row, a 2MB page will typically cover multiple rows, some of which will be in the same bank.

 

Am I wrong to say that if huge pages are enabled on a Linux system, when we allocate memory they are very likely to be contiguous in physical memory as well? And that is why we can use relative physical addresses?

However, since we only have virtual memory addresses, how do we find these physical addresses even if we have the offsets in virtual memory?

[david...@gmail.com]

The reason that you would want a page map is so you would know what virtual pages would map to what rows in the ram.

But, if you know the size of every row (if its like 4k for example) you don't need to know the real physical mapping. Its enought to know the length of every row (say n) and you read from x=n and y=x+2n, and the target cell will be in between them (at x+n).

This is the next paragraph :

Yoongu Kim et al take this approach. They pick Y = X + 8MByte based on knowledge of the physical address mapping used by the memory controllers in Intel and AMD’s CPUs.