From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6964 invoked by alias); 6 Mar 2012 19:08:11 -0000 Received: (qmail 6950 invoked by uid 22791); 6 Mar 2012 19:08:09 -0000 X-SWARE-Spam-Status: No, hits=-6.8 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; Tue, 06 Mar 2012 19:07:56 +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 q26J7fm0026474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Mar 2012 14:07:53 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q26HtUIt001202; Tue, 6 Mar 2012 12:55:31 -0500 Message-ID: <4F564F92.8060100@redhat.com> Date: Tue, 06 Mar 2012 19:08:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Thomas Schwinge CC: Kevin Buettner , gdb-patches@sourceware.org Subject: Re: [PATCH] [SH] Prologue skipping if there is none References: <87pqdgciho.fsf@schwinge.name> <20120215075413.1313f7fa@mesquite.lan> <20120215165907.33f2e9a6@mesquite.lan> <8739aad9il.fsf@schwinge.name> <20120216182544.36b41a1b@mesquite.lan> <87mx8da3b9.fsf@schwinge.name> <20120220162029.2082b6a1@mesquite.lan> <87wr7c7aop.fsf@schwinge.name> <20120224144657.36bbd09f@mesquite.lan> <87r4xd528y.fsf@schwinge.name> <87d38w4rxr.fsf@schwinge.name> <20120301171847.306829ba@mesquite.lan> <87mx7z2qwc.fsf@schwinge.name> <4F50B664.3090307@redhat.com> <87k4332ipm.fsf@schwinge.name> In-Reply-To: <87k4332ipm.fsf@schwinge.name> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: 2012-03/txt/msg00201.txt.bz2 On 03/02/2012 02:14 PM, Thomas Schwinge wrote: > Hi! > > On Fri, 2 Mar 2012 12:00:36 +0000, Pedro Alves wrote: >> On 03/02/2012 11:17 AM, Thomas Schwinge wrote: >>> On Thu, 1 Mar 2012 17:18:47 -0700, Kevin Buettner wrote: >>>>> On Thu, 01 Mar 2012 10:00:00 +0100 >>>>> Thomas Schwinge wrote: >>>>> >>>>>>> @@ -594,6 +590,7 @@ sh_analyze_prologue (struct gdbarch *gdb >>>>>>> { >>>>>>> sav_reg = reg; >>>>>>> offset = (inst & 0xff) << 1; >>>>>>> + /* TODO: check that this is a valid address. */ >>>>>>> sav_offset = >>>>>>> read_memory_integer ((pc + 4) + offset, 2, byte_order); >>>>>>> } > >> In this case, what's >> necessary to just fix that particular issue? > > The issue here is that external data (a malicious executable that is > being debugged) might possibly cause GDB to do arbitrary things due to > corrupting its internal state. (I don't know if GDB development is > generally paying attention to such ``detail'', but it certainly is an > attack vector if you're debugging a binary that has been provided by a > third party.) > > For inaccessible addresses, target_read_memory returns EIO, which causes > read_memory to invoke throw_error: ``Cannot access memory at address > 0xfffffffe''; that's fine. > > For improper but accessible addresses, it is more difficult to predict > what might happen in the following. The value will be propagated into a > frame cache's sp_offset and saved_sp. From there on, we have to rely on > the frame unwinding machinery to reliably detect any failures or > inconsistencies. I really have trouble understanding the point, unless you're talking about GDB ending up touching random volatile memory mapped registers in the inferior it should not, and that affecting the system. Considering something like this is a bigger problem that applies to every access, so it doesn't justify an isolated and vague comment in the code like that, in my view. -- Pedro Alves