Re: [RFA] s/PIOD_WRITE_D/PIOD_WRITE_I in inf-ptrace.c

[Daniel Jacobowitz <drow@false.org>]

On Sun, Nov 20, 2005 at 02:12:40PM +0100, Mark Kettenis wrote:
> The motivation for the change in OpenBSD is very much related to an
> issue we had when using gdb to debug a nasty X problem.  The new
> malloc(3) in OpenBSD 3.8 is pretty aggressive in inserting "guard
> pages" before and after allocated memory to catch buffer overflows.
> The guard pages actually do exists in the page map but have read,
> write and execute permission removed from them.  At one point we were
> tracking a problem in X where some code in X was accessing memory
> beyond the allocated area, i.e. in the guard page.  The program would
> segfault upon accessing that guard page, but when running in gdb, it
> would appear if nothing was wrong.  Examining the memory (using "x" or
> "print") in gdb happily returned the contents of the guard page
> because ptrace(2) was temporarily lifting the page protections.
> 
> I'm still thinking about what needs to be changed in gdb to make
> things work properly.  Somehow we must differentiate between access to
> I-space and access to D-space.  But at least OpenBSD now provides the
> low-level support to do that.  Meanwhile, this patch will do as a
> stopgap.

Is this really the right way to solve the problem of GDB ignoring
protections?  Don't you have a way for the debugger to query the
inferior's memory map in *BSD?  Then it can do all the permission
checks that it wants to, including things like "this instruction is
faulting because the page is rw- instead of r-x".

The bypass-permissions and dont-bypass-permissions variants may be
useful to somewhat simpler programs anyway.

> I'd really like to see this change in GDB 6.4, because otherwise it
> will not work at all on OpenBSD 3.9.  But since the release of OpenBSD
> 3.9 is still months ahead, having a GDB 6.4.1 with this issue fixed
> would be fine for me too.

I have no objection to putting this in 6.4.

-- 
Daniel Jacobowitz
CodeSourcery, LLC