This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 0/7 V2] Trust readonly sections if target has memory protection


On 09/10/2013 12:05 PM, Yao Qi wrote:
Even on systems that have an MMU that can mark pages read-only, system
>calls like mprotect(2) can be used to make read-only pages
>(temporarily) writable.  This is done by the OpenBSD dynamic linker
>during relocation processing.  I expect other systems implementing
>strict W^X to do the same.  Enabling trust-readonly-sections on such
>systems would be a bad idea.
If GDB can monitor mprotect syscall, it can still trust readonly
sections if their pages are not changed to writable by mprotect.

GDB is able to 'catch syscall mprotect', only on linux-nat
unfortunately.  It doesn't work on remote target

    "catch syscall" support in the remote protocol
    https://sourceware.org/bugzilla/show_bug.cgi?id=13585

Similarly, GDB can monitor function VirtualProtect on Windows target
too.

Do we have a concrete criteria to reject or accept this patch series?
I need this to plan for my next step.  Here are some possibilities in
my brain,

1. This series is rejected because GDB is incorrect when program uses mprotect and change some readonly pages, unless....
 2.  ... GDB is able to monitor syscall mprotect, and trust readonly
sections if they are still readonly in the process's space.
 3.  This series can be accepted.  I am wondering how popular that user
program modifies readonly sections in process space by mprotect.  Do we
really sacrifice the performance of GDB in some common cases, like
remote debugging, for this corner case?  I'd like to add doc for the
case using mprotect and remind user to turn trust-readonly-sections off
by him/her self.

--
Yao (éå)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]