From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5512 invoked by alias); 5 Jul 2010 17:22:53 -0000 Received: (qmail 5437 invoked by uid 22791); 5 Jul 2010 17:22:52 -0000 X-SWARE-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 05 Jul 2010 17:22:47 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o65HMXKM004642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Jul 2010 13:22:34 -0400 Received: from host0.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o65HMV1C015420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jul 2010 13:22:33 -0400 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.4/8.14.4) with ESMTP id o65HMVXc023625; Mon, 5 Jul 2010 19:22:31 +0200 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.4/8.14.4/Submit) id o65HMUXh023624; Mon, 5 Jul 2010 19:22:30 +0200 Date: Mon, 05 Jul 2010 17:22:00 -0000 From: Jan Kratochvil To: Joel Brobecker Cc: gdb-patches@sourceware.org Subject: Re: ping: [patch 1/6] PIE: Attach binary even after re-prelinked underneath Message-ID: <20100705172230.GA23280@host0.dyn.jankratochvil.net> References: <20100329153031.GA31671@host0.dyn.jankratochvil.net> <20100609150753.GA7183@host0.dyn.jankratochvil.net> <20100629174216.GR2595@adacore.com> <20100704101635.GA6875@host0.dyn.jankratochvil.net> <20100705170602.GY2595@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100705170602.GY2595@adacore.com> User-Agent: Mutt/1.5.20 (2009-12-10) X-IsSubscribed: yes 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 X-SW-Source: 2010-07/txt/msg00080.txt.bz2 On Mon, 05 Jul 2010 19:06:02 +0200, Joel Brobecker wrote: > > gdb/ > > 2010-07-02 Jan Kratochvil > > Joel Brobecker > > > > Fix attaching to PIEs prelinked on the disk after the process was > > started. > > * solib-svr4.c (svr4_exec_displacement): New variable arch_size. > > Verify it against bfd_get_arch_size. Try to match arbitrary > > displacement for the phdrs comparison. > > > > gdb/testsuite/ > > 2010-07-02 Jan Kratochvil > > Joel Brobecker > > > > * gdb.base/break-interp.exp: Run $binpie with new value "ATTACH", new > > code for it. New variable relink_args. > > (prelinkYES): Call prelinkNO. > > (test_attach): Accept new parameter relink_args. Re-prelink the binary > > in such case. Move the core code to ... > > (test_attach_gdb): ... a new function. Send GDB command "file". > > Extend expected "Attaching to " string. > > This is OK, with one English error in one of my suggestions (mea culpa). The "easier" -> "more easily" one? My fault, I forgot to include this fix by you, sorry. > > + /* PT_GNU_STACK is an exception by being never relocated by > > + prelink as its addresses are always zero. */ > > I understand why you mean, now, about the PT_GNU_STACK entry not being > changed during the prelink. But I don't get the relationship between > this comment and the code surrounding it. Can you explain that? Code simplified for better readability in this mail: /* PT_GNU_STACK is an exception by being never relocated by prelink as its addresses are always zero. */ if (memcmp (phdrp, phdr2p, sizeof (*phdrp)) == 0) continue; /* Check also other adjustment combinations - PR 11786. */ *buf_vaddr_p -= displacement; *buf_paddr_p -= displacement; if (memcmp (phdrp, phdr2p, sizeof (*phdrp)) == 0) continue; For detected DISPLACEMENT value 0x3000000000 the latter test works: PHDR 0x000040 0x0000000000000040 0x0000000000000040 0x0001c0 0x0001c0 R E 0x8 -> PHDR 0x000040 0x0000003000000040 0x0000003000000040 0x0001c0 0x0001c0 R E 0x8 as 0x0000003000000040 - 0x3000000000 == 0x0000000000000040. But in the same executable there is also GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x8 -> GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x8 but 0x0000000000000000 - 0x3000000000 == 0xffffffd000000000 and thus 0x0000000000000000 - 0x3000000000 != 0x0000000000000000 and we would fail the verification despite the executable perfectly matches. I believe one should be looking at some two `readelf -Wa' dumps of an executable with two prelink addresses while checking this code so it should be apparent during real updates of that code. Thanks, Jan