PaX MPROTECT gdb and software breakpoints

[christos%zoulas.com@localhost (Christos Zoulas)]

Hello,

Now that PaX MPROTECT is the default on 3 platforms (amd64, i386, and evbarm)
the problem of software breakpoints and gdb has surfaced. Namely if MPROTECT
is on, and you try to set a breakpoint you get:

(gdb) break main
Breakpoint 1 at 0x107e0: file aslr.c, line 8.
(gdb) r
Starting program: /u/christos/a.out 
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x107e0
Cannot insert breakpoint -1.
Temporarily disabling shared library breakpoints:
breakpoint #-1


Gdb tries to write the breakpoint instruction in the text segment,
uvm_io() calls uvm_map_extract(... | UVM_EXTRACT_FIXPROT), but the
max protection for the text segment does not allow writes anymore.

There are three solutions I can think of (maybe you can think of a better
one):

1. Leave it as it is and document that people will have to paxctl +m
   the executables that they need to mprotect before they can debug
   it.
2. create a uvm_io1() and a new UVM_EXTRACT that breaks MPROTECT and
   fetches with the right mappings. I don't like that, it breaks MPROTECT
   and uvm contracts. But it has the advantage of working on already
   started process we PT_ATTACH to.
3. when process is execed and is already traced (PT_TRACE_ME), disable
   MPROTECT. This should work with processes started from gdb, but
   not attached ones. We will still need to explain that to attach
   and insert breakpoints you need to set MPROTECT off.

Opinions?

christos