Re: PaX MPROTECT gdb and software breakpoints

[Martin Husemann <martin%duskware.de@localhost>]

On Sat, May 21, 2016 at 04:21:45PM -0400, Christos Zoulas wrote:
> 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.

Tricky. I find (3) is a bit too limited, but it is the only clean way.
Like David suggested, (1) could be extended by a gdb message explaining
the issue.

(2) is evil, but may be needed. Of course we should restrict the new
path to traced processes, and maybe even limit it to root additionally?

Martin