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

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Thu, 12 Sep 2013 16:29:26 +0800
> From: Yao Qi <yao@codesourcery.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....

I'm certainly not outright rejecting it.  But you'll certainly need to
rethink in which contexts it is safe/acceptable that "auto" actually
turns on the trust-readonly-sections feature.  That decision should
probably be done on a per-architecture, per-OS basis, and only for
remote debugging.

>   2.  ... GDB is able to monitor syscall mprotect, and trust readonly
> sections if they are still readonly in the process's space.

Of course monitoring syscalls comes with a performance penalty as
well.  Worse, it will affect the timing of the program you're
debugging, so turning it on by default would probably be a seriously
bad idea unless you can intercept "just" the mprotect syscalls.

>   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.

It will happen for *any* dynamically linked binary on OpenBSD.  I
expect the same to be true for many security-enhanced Linux variants.
But running strace on a randomly chosen binary from Ubuntu 10.4
suggests its not common there.  There are a couple of mprotect calls,
but none that add PROT_WRITE permission.

Personally, I think trust-readonly-sections remains a dangerous
feature that should only be enabled by people who know what they're
doing.  Having GDB print values for variables that are different from
what the program itself is actually seeing would be very frustrating
and potentially waste a lot of my time.  But I only really care about
native debugging.