This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 0/7 V2] Trust readonly sections if target has memory protection
- From: Yao Qi <yao at codesourcery dot com>
- To: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- Cc: <gdb-patches at sourceware dot org>
- Date: Thu, 12 Sep 2013 16:29:26 +0800
- Subject: Re: [PATCH 0/7 V2] Trust readonly sections if target has memory protection
- Authentication-results: sourceware.org; auth=none
- References: <1378432920-7731-1-git-send-email-yao at codesourcery dot com> <1378641807-24256-1-git-send-email-yao at codesourcery dot com> <201309091916 dot r89JGbpf009986 at glazunov dot sibelius dot xs4all dot nl> <522E9A8A dot 7040509 at codesourcery dot com>
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 (éå)