From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32516 invoked by alias); 2 Feb 2013 12:25:38 -0000 Received: (qmail 32472 invoked by uid 22791); 2 Feb 2013 12:25:34 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS 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; Sat, 02 Feb 2013 12:25:22 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r12CPJfi007859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 2 Feb 2013 07:25:19 -0500 Received: from host2.jankratochvil.net (ovpn-116-88.ams2.redhat.com [10.36.116.88]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r12CPEVM003719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 2 Feb 2013 07:25:17 -0500 Date: Sat, 02 Feb 2013 12:25:00 -0000 From: Jan Kratochvil To: Aleksandar Ristovski Cc: "gdb-patches@sourceware.org" Subject: Re: [patch] validate binary before use Message-ID: <20130202122514.GA30057@host2.jankratochvil.net> References: <50DCB787.6020601@qnx.com> <20121227211328.GA5739@host2.jankratochvil.net> <50DCBBD1.7000707@qnx.com> <5107F591.304@qnx.com> <20130130191646.GA1034@host2.jankratochvil.net> <510A7E4B.4040608@qnx.com> <20130201030610.GA12800@host2.jankratochvil.net> <510BD1BF.2050209@qnx.com> <20130201200418.GA18674@host2.jankratochvil.net> <510C343D.8020500@qnx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <510C343D.8020500@qnx.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2013-02/txt/msg00044.txt.bz2 On Fri, 01 Feb 2013 22:31:41 +0100, Aleksandar Ristovski wrote: > I will not claim familiarity with how linux works, but auxv > typically has information for the executable only, not the shared > objects OK, sorry, my comment was not appropriate, I remembered the function which finally end up in GDB incorrectly. If you are interested in shared library base VMA you could take link_map->l_ld and search /proc/PID/maps where it is located, subtract mapping offset and you get the base VMA where ELF headers starts. This is possible in gdbserver/linux-low.c but not possible in solib-svr4.c (which is cross-OS). gdbserver/linux-low.c currently does such computation for the main executable but it does not do it for any of the shared libraries. >From ELF headers one can find Program headers, PT_NOTE and the build-id. BTW your patch currently verifies only shared libraries. I do not request so but a complete solution could verify also build-id of the executable. > Therefore, the only clue for deterministic and straight forward > relocation calculus for a tool like gdb is l_addr from the link map. Not from l_addr but l_ld is an absolute address of the DYNAMIC segment/section. From that one can derive something but only with /proc/PID/maps one can derive the ELF header VMA. > If gnu ld BTW this is more ld.so (PT_INTERP, /lib64/ld-linux-x86-64.so.2), not /usr/bin/ld. > is not setting it up when "successful prelink" happens it > is making a mistake: As I said it is not a mistake but it was rather an incorrect comment at l_addr. l_addr is now officially defined as: + ElfW(Addr) l_addr; /* Difference between the address in the ELF + file and the addresses in memory. */ http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=542f94662e8235d9917b0783df70bcdf9d729503 > 0 load base may be legitimate and true in some > cases on some systems. Furhter, it unnecessary introduces this > difference when it would probably change very little (nothing?) if > it set it up correctly to what the load base really is, Setting it to the absolute address would break tools like GDB which already expect it is the "difference" described above. > just as it does for "unsuccessful" prelinks or non-prelinked objects. It is not just "0 or the address". It can be arbitrary number if you prelink a library to address X and X is not free upon its loading so it gets placed at Y. Then L_ADDR is set to "Y - X" which is none of X, Y or 0. Thanks, Jan