Linux页面表的过程

Question

Intel core i5, Ubunu 16.04

I'm reading about the memory paging here and now trying to experiment with it. I wrote a simple assembly program for getting Segmentation Fault and ran in gdb. Here it is:

 section .text
     global _start

 _start:
     mov rax, 0xFFFFFFFFFFFF0A31
     mov [val], eax
     mov eax, 4
     mov ebx, 1
     mov ecx, val
     mov edx, 2

     int 0x80

     mov eax, 1
     int 0x80

 segment .bss
     dummy resb 0xFFA
     val resb 1

I assemble and link this into a 64-bit ELF static executable.

As far as I read each process has its own Page Table which cr3 register points to. Now I would like to look at the page table myself? Is it possible to find info about process page table in Linux?

Answer 1

You would need to have a program compiled as a kernel module to read the page tables. I am sure there are projects out there to do that.

Take a look here: https://github.com/jethrogb/ptdump

Seems to describe what you want

Answer 2

You can see all the mappings your process has in /proc/PID/smaps . This tells you what you can access without getting a SIGSEGV.

This is not the same thing as your cr3 page table, because the kernel doesn't always "wire" all your mappings. ie a hardware page fault isn't always a SIGSEGV: the kernel page-fault handler checks whether your process logically has that memory mapped and corrects the situation, or whether you really did violate the memory protections.

---

After an mmap() system call, or on process startup to map the text / data / BSS segments, you logically have memory mapped, but Linux might have decided to be lazy and not provide any physical pages yet. (eg maybe the pages aren't in the pagecache yet, so there's no need to block until you try to actually touch that memory and get a page fault).

Or for BSS memory, multiple logical pages might start out copy-on-write mapped to the same physical page of zeros. Even though according to Unix semantics your memory is read-write, the page tables would actually have read-only mappings. Writing a page will page-fault, and the kernel will point that entry at a new physical page of zeros before returning to your process at the instruction which faulted (which will then be re-run and succeed).

Anyway, this doesn't directly answer your question, but might be part of what you actually want. If you want to look under the hood, then sure have fun looking at the actual page tables, but you generally don't need to do that. smaps can tell you how much of a mapping is resident in memory.

See also what does pss mean in /proc/pid/smaps for details on what the fields mean.

---

BTW, see Why in 64bit the virtual address are 4 bits short (48bit long) compared with the physical address (52 bit long)? for a nice diagram of the 4-level page table format (and how 2M / 1G hugepages fit in).

Answer 3

I wrote a simple assembly program for getting Segmentation Fault and ran in gdb.... As far as I read each process has its own Page Table which cr3 register points to. Now I would like to look at the page table myself? Is it possible to find info about process page table in Linux?

The operating system maintains the page tables. They are protected from user-mode access (as you are trying to do).

To understand how protection works you are going to need to understand the difference between processor modes (eg, Kernel and User) and how the processor shifts between these modes.

In short, however, trying to write code to examine page tables as you are doing is a dead end. You are better off learning about page table structure from books rather than trying to write code. I suggest looking at the Intel manuals.

https://software.intel.com/en-us/articles/intel-sdm

Sadly, this is rather dry and Intel writes the worst processor manuals I have seen. I recommend looking exclusively at 64-bit mode. Intel's 32-bit is overly complicated. If there is talk about segments, you are reading 32-bit and can ignore it. Intel's documentation never specifies whether addresses are physical or logical. So you may need to look at on-line lectures for clarification.

To supplement this reading, you can look at the Linux Source code. https://github.com/torvalds/linux

To conclude, it appears you need two prerequisites to get where you want to go: (1) processor modes; and (2) page table structure.