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: Tue, 10 Sep 2013 12:05:30 +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>
On 09/10/2013 03:16 AM, Mark Kettenis wrote:
What does "memory protection" mean? That a target has an MMU that
allows pages to be marked read-only? That really is more a hardware
feature than a OS aatribute.
"memory protection" means prevent modifying readonly sections or regions
of the process. "memory protection" is a joint effort by MMU
and OS together, IMO.
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.
--
Yao (éå)