Re: PaX MPROTECT gdb and software breakpoints

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

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

I occasionally need to gdb-attach to a running process (usually a daemon)
to try to understand what's going on. I think it's important to keep
the ability to attach to a running process, which has not been
started in a specific way before.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--