views:

122

answers:

2

I'm wondering if there's a way to write-protect every page in a Linux process' address space (from inside of the process itself, by way of mprotect()). By "every page", I really mean every page of the process's address space that might be written to by an ordinary program running in user mode -- so, the program text, the constants, the globals, and the heap -- but I would be happy with just constants, globals, and heap. I don't want to write-protect the stack -- that seems like a bad idea.

One problem is that I don't know where to start write-protecting memory. Looking at /proc/pid/maps, which shows the sections of memory in use for a given pid, they always seem to start with the address 0x08048000, with the program text. (In Linux, as far as I can tell, the memory of a process is laid out with the program text at the bottom, then constants above that, then globals, then the heap, then an empty space of varying size depending on the size of the heap or stack, and then the stack growing down from the top of memory at virtual address 0xffffffff.) There's a way to tell where the top of the heap is (by calling sbrk(0), which simply returns a pointer to the current "break", i.e., the top of the heap), but not really a way to tell where the heap begins.

If I try to protect all pages from 0x08048000 up to the break, I eventually get an mprotect: Cannot allocate memory error. I don't know why mprotect would be allocating memory anyway -- and Google is not very helpful. Any ideas?

By the way, the reason I want to do this is because I want to create a list of all pages that are written to during a run of the program, and the way that I can think of to do this is to write-protect all pages, let any attempted writes cause a write fault, then implement a write fault handler that will add the page to the list and then remove the write protection. I think I know how to implement the handler, if only I could figure out which pages to protect and how to do it.

Thanks!

A: 

Start simple. Write-protect a few page and make sure your signal handler works for these pages. Then worry about expanding the scope of the protection. For example, you probably do not need to write-protect the code-section: operating systems can implement write-or-execute protection semantics on memory that will prevent code sections from ever being written to:

Noah Watkins
Yeah, for this problem we can assume no self-modifying code for now. I'd be OK with either write-protecting the code section or not, whichever is easier.
Lindsey Kuper
Actually what I was trying to say is that your code sections are most likely already write-protected.
Noah Watkins
+3  A: 

You recieve ENOMEM from mprotect() if you try to call it on pages that aren't mapped.

Your best bet is to open /proc/self/maps, and read it a line at a time with fgets() to find all the mappings in your process. For each writeable mapping (indicated in the second field) that isn't the stack (indicated in the last field), call mprotect() with the right base address and length (calculated from the start and end addresses in the first field).

Note that you'll need to have your fault handler already set up at this point, because the act of reading the maps file itself will likely cause writes within your address space.

caf
Thanks -- I was hoping that there would be some way around having to hand-parse /proc/self/maps, but it appears that there isn't (from the discussion at http://stackoverflow.com/questions/269314/is-there-a-better-way-than-parsing-proc-self-maps-to-figure-out-memory-protectio).
Lindsey Kuper