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 <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
