From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22249 invoked by alias); 4 Apr 2013 13:03:15 -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 22237 invoked by uid 89); 4 Apr 2013 13:03:13 -0000 X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,TW_BJ autolearn=ham version=3.3.1 Received: from na3sys009aog119.obsmtp.com (HELO na3sys009aog119.obsmtp.com) (74.125.149.246) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 04 Apr 2013 13:03:09 +0000 Received: from mx10.qnx.com ([209.226.137.110]) (using TLSv1) by na3sys009aob119.postini.com ([74.125.148.12]) with SMTP ID DSNKUV16C/tGrBL2rUqVxm2jDBHa+jhPuiEL@postini.com; Thu, 04 Apr 2013 06:03:09 PDT Received: by mx10.qnx.com (Postfix, from userid 500) id 3055E20E48; Thu, 4 Apr 2013 09:03:07 -0400 (EDT) Received: from exhts.ott.qnx.com (exch1 [10.222.2.137]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx10.qnx.com (Postfix) with ESMTPS id A0B1F1FD6E; Thu, 4 Apr 2013 09:03:06 -0400 (EDT) Received: from [10.222.96.215] (10.222.2.5) by EXCH1.ott.qnx.com (10.222.2.137) with Microsoft SMTP Server id 14.2.318.4; Thu, 4 Apr 2013 09:03:06 -0400 Message-ID: <515D7A09.5010305@qnx.com> Date: Thu, 04 Apr 2013 17:15:00 -0000 From: Aleksandar Ristovski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 Newsgroups: gmane.comp.gdb.patches To: Jan Kratochvil CC: Subject: Re: [patch] validate binary before use References: <510A7EB0.90702@qnx.com> <51278A2A.9000802@qnx.com> <512E42D1.3040101@qnx.com> <514C58B2.6090701@qnx.com> <20130328183727.GA14798@host2.jankratochvil.net> <515B0632.1040502@qnx.com> <20130402165306.GA9479@host2.jankratochvil.net> <515B12D1.7050505@qnx.com> <20130403180917.GA6102@host2.jankratochvil.net> <515CDF7F.5020403@qnx.com> <20130404081302.GA4099@host2.jankratochvil.net> In-Reply-To: <20130404081302.GA4099@host2.jankratochvil.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-04/txt/msg00104.txt.bz2 On 13-04-04 04:13 AM, Jan Kratochvil wrote: > On Thu, 04 Apr 2013 04:03:43 +0200, Aleksandar Ristovski wrote: >> Actually, as I think about this more, we can not use section from >> possibly unrelated bfd to read build-id in native debugging case. At >> a minimum, we can not store such build-id as abfd may not even >> relate to what's in target's memory. > > Why? > > If the target shared library does not match then GDB will read some random > memory. The target shared library may not even have any build-id. > > As the build-id has 160 bits there is 1:2^160 probability of a false positive, > that is safe enough. The problem is, we could 'remember' build-id that is garbage. I will add checking for GNU\0 and note type, and then the likelihood that somewhat random memory will match namesz, name and type will be very low (though the likelihood has nothing to do with the 160 bits of build-id; build-id is not necessarily 160 bits either). The rest of the e-mail applies: > > >> The chunk of code that is in svr4_relocate_section_addresses in the > you probably mean solib_map_sections > >> latest version of the patch needs to go back to svr4_validate, and >> not store build-id. > > > I do not understand this whole mail, it would be best to provide a countercase > where the current patchset does not behave correctly. The above should explain why is current patchset incorrect (in particular patch #7). The rest is about design and duplicated functionality. The functionality of gdbserver where it fetches the list is exactly the same what -nat can do; in fact this could be the same code; and then solib-svr4.c deals only with TARGET_OBJECT_LIBRARIES_SVR4. The infrastructure is in place. Impact on solib-svr4.c: svr4_validate would be exactly as it is now, simply check. svr4_relocate_section_addresses would not need the kludge for reading build-id, there would be only one path of getting build-id. Not to be neglected is that by doing so, it would be possible to look for the debug binary directly, by using build-id instead of opening objfile and then looking for separate_debug_fie. --- Aleksandar From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22731 invoked by alias); 4 Apr 2013 13:03:20 -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 22702 invoked by uid 89); 4 Apr 2013 13:03:20 -0000 X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,FSL_HELO_BARE_IP_2,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_NUMERIC_HELO,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_BJ autolearn=ham version=3.3.1 Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 04 Apr 2013 13:03:19 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UNjpM-0001J2-O9 for gdb-patches@sourceware.org; Thu, 04 Apr 2013 15:03:40 +0200 Received: from 209.226.137.106 ([209.226.137.106]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 04 Apr 2013 15:03:40 +0200 Received: from aristovski by 209.226.137.106 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 04 Apr 2013 15:03:40 +0200 To: gdb-patches@sourceware.org From: Aleksandar Ristovski Subject: Re: [patch] validate binary before use Date: Thu, 04 Apr 2013 18:11:00 -0000 Message-ID: <515D7A09.5010305@qnx.com> References: <510A7EB0.90702@qnx.com> <51278A2A.9000802@qnx.com> <512E42D1.3040101@qnx.com> <514C58B2.6090701@qnx.com> <20130328183727.GA14798@host2.jankratochvil.net> <515B0632.1040502@qnx.com> <20130402165306.GA9479@host2.jankratochvil.net> <515B12D1.7050505@qnx.com> <20130403180917.GA6102@host2.jankratochvil.net> <515CDF7F.5020403@qnx.com> <20130404081302.GA4099@host2.jankratochvil.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gdb-patches@sourceware.org User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 In-Reply-To: <20130404081302.GA4099@host2.jankratochvil.net> X-SW-Source: 2013-04/txt/msg00105.txt.bz2 Message-ID: <20130404181100.TsPmmGXF5QblsUQ3hS6F2nD0Pd7PDMiLniGvdI6z1_s@z> On 13-04-04 04:13 AM, Jan Kratochvil wrote: > On Thu, 04 Apr 2013 04:03:43 +0200, Aleksandar Ristovski wrote: >> Actually, as I think about this more, we can not use section from >> possibly unrelated bfd to read build-id in native debugging case. At >> a minimum, we can not store such build-id as abfd may not even >> relate to what's in target's memory. > > Why? > > If the target shared library does not match then GDB will read some random > memory. The target shared library may not even have any build-id. > > As the build-id has 160 bits there is 1:2^160 probability of a false positive, > that is safe enough. The problem is, we could 'remember' build-id that is garbage. I will add checking for GNU\0 and note type, and then the likelihood that somewhat random memory will match namesz, name and type will be very low (though the likelihood has nothing to do with the 160 bits of build-id; build-id is not necessarily 160 bits either). The rest of the e-mail applies: > > >> The chunk of code that is in svr4_relocate_section_addresses in the > you probably mean solib_map_sections > >> latest version of the patch needs to go back to svr4_validate, and >> not store build-id. > > > I do not understand this whole mail, it would be best to provide a countercase > where the current patchset does not behave correctly. The above should explain why is current patchset incorrect (in particular patch #7). The rest is about design and duplicated functionality. The functionality of gdbserver where it fetches the list is exactly the same what -nat can do; in fact this could be the same code; and then solib-svr4.c deals only with TARGET_OBJECT_LIBRARIES_SVR4. The infrastructure is in place. Impact on solib-svr4.c: svr4_validate would be exactly as it is now, simply check. svr4_relocate_section_addresses would not need the kludge for reading build-id, there would be only one path of getting build-id. Not to be neglected is that by doing so, it would be possible to look for the debug binary directly, by using build-id instead of opening objfile and then looking for separate_debug_fie. --- Aleksandar