Re: PaX MPROTECT gdb and software breakpoints

[David Brownlee <abs%netbsd.org@localhost>]

On 21 May 2016 at 21:21, Christos Zoulas <christos%zoulas.com@localhost> wrote:
>
> 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.

Possibly a variant on 1 which includes a patch to gdb to suggest this
case when the breakpoint insertion fails, so someone who has not
already read about the situation has direct information on how to
"fix" it when they hit it