From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30291 invoked by alias); 12 Sep 2013 09:49:25 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 30272 invoked by uid 89); 12 Sep 2013 09:49:24 -0000 Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 12 Sep 2013 09:49:24 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_20,KHOP_THREADED autolearn=ham version=3.3.2 X-HELO: glazunov.sibelius.xs4all.nl Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3) with ESMTP id r8C9nFGg021113; Thu, 12 Sep 2013 11:49:15 +0200 (CEST) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3/Submit) id r8C9nFsJ016506; Thu, 12 Sep 2013 11:49:15 +0200 (CEST) Date: Thu, 12 Sep 2013 09:49:00 -0000 Message-Id: <201309120949.r8C9nFsJ016506@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: yao@codesourcery.com CC: gdb-patches@sourceware.org In-reply-to: <52317B66.3020602@codesourcery.com> (message from Yao Qi on Thu, 12 Sep 2013 16:29:26 +0800) Subject: Re: [PATCH 0/7 V2] Trust readonly sections if target has memory protection References: <1378432920-7731-1-git-send-email-yao@codesourcery.com> <1378641807-24256-1-git-send-email-yao@codesourcery.com> <201309091916.r89JGbpf009986@glazunov.sibelius.xs4all.nl> <522E9A8A.7040509@codesourcery.com> <52317B66.3020602@codesourcery.com> X-SW-Source: 2013-09/txt/msg00377.txt.bz2 > Date: Thu, 12 Sep 2013 16:29:26 +0800 > From: Yao Qi > > 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.