Linux page table of the process

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?

Application programs can't access the page table, it's only accessible to the kernel. — Barmar, Nov 09 '17 at 18:10
@Barmar But maybe we can find some info about in `/proc` or somewhere else in Linux? — St.Antario, Nov 09 '17 at 18:11
Unix.stackexchange.com would probably be a better place to ask about that. — Barmar, Nov 09 '17 at 18:12
Also note it's changing all the time. It would be pretty useless information unless maybe you locked pages into memory. — Jester, Nov 09 '17 at 18:13
@Jester Is it standartized? I mean I just want to understand the format of it on my architecture. — St.Antario, Nov 09 '17 at 18:14
@St.Antario No, you can't do it in gdb. Just about everything you do as a user deals with virtual memory, not physical memory. — Barmar, Nov 09 '17 at 18:14
Read the _Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 3: System Programming Guide, CHAPTER 4 PAGING_ — Jester, Nov 09 '17 at 18:16
You can get an idea of the memory layout of a process by looking at `/proc//smaps` — Michael Petch, Nov 09 '17 at 18:23
@MichaelPetch Very good point. Thanks. It seems I can get the human readable memory layout devided by segments and pages in human readable format. Could not you please post it as an answer? — St.Antario, Nov 09 '17 at 18:27
Be my guest and self answer (answering your own question is acceptable on SO and you have my blessing) — Michael Petch, Nov 09 '17 at 18:28
@St.Antario `/proc/$pid/map` contains the memory map for process `$pid`. The page table itself is not very interesting as it is constantly altered by the kernel and doesn't really indicate which pages you are allowed to access. — fuz, Nov 09 '17 at 21:30

spitfire21 · Answer 1 · 2017-11-09T18:16:57.953

3

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

edited Nov 09 '17 at 18:16

answered Nov 09 '17 at 18:15

spitfire21

103
4

This seems like it would be more appropriate as a comment, if you can't provide more specific details. – Barmar Nov 09 '17 at 18:16

Peter Cordes · Accepted Answer · 2017-11-09T18:43:05.217

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. i.e. 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. (e.g. 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).

score 1 · Answer 3 · answered Nov 09 '17 at 20:16

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 (e.g., 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.

Nothing prevents you from writing a Linux kernel module that takes a snap shot of the page table for the calling process and make it available to the user process via something like IOCTL (or some other mechanism) — Michael Petch, Nov 09 '17 at 20:46
But obviously, this guy is not up to that or using kernel mode debuggers. — user3344003, Nov 09 '17 at 21:46

Linux page table of the process

3 Answers3

Related