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: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: yao at codesourcery dot com
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 9 Sep 2013 21:16:37 +0200 (CEST)
- 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>
> From: Yao Qi <yao@codesourcery.com>
> Date: Sun, 8 Sep 2013 20:03:20 +0800
>
> Here is the V2, to address comments to V1,
>
> - Warn about writes to readonly sections if trust-readonly-sections
> is enabled. (patch 1/7)
> - Windows targets have memory protection. (patch 7/7)
>
> Do some refactor in Windows related targets, add a new function
> windows_init_abi (done by patch 3/7). It paves the way for patch
> 7/7.
>
> Below the description of this series in V1:
> https://sourceware.org/ml/gdb-patches/2013-09/msg00193.html
>
> When option "trust-readonly-sections" was introduced in this patch
> http://www.sourceware.org/ml/gdb-patches/2002-01/msg00711.html, there
> was the discussion to turn it on in default. However, we didn't do
> that because we have a concern that bad or buggy program may modify the
> code on the non-memory protected system. On the other hand, it is
> highly recommended to turn this on in remote debugging.
>
> I am wondering if we can teach GDB to trust read-only sections if it
> knows the target system has memory protection. For some targets, such
> as linux, we know they do have memory protection. This is what this
> patch series tries to do.
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.
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.