This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] s/PIOD_WRITE_D/PIOD_WRITE_I in inf-ptrace.c
- From: Daniel Jacobowitz <drow at false dot org>
- To: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- Cc: gdb-patches at sourceware dot org
- Date: Sun, 20 Nov 2005 11:08:48 -0500
- Subject: Re: [RFA] s/PIOD_WRITE_D/PIOD_WRITE_I in inf-ptrace.c
- References: <200511201312.jAKDCe8r008006@elgar.sibelius.xs4all.nl>
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