From: Pedro Alves <palves@redhat.com>
To: Thomas Schwinge <thomas@codesourcery.com>
Cc: Kevin Buettner <kevinb@redhat.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] [SH] Prologue skipping if there is none
Date: Tue, 06 Mar 2012 19:08:00 -0000 [thread overview]
Message-ID: <4F564F92.8060100@redhat.com> (raw)
In-Reply-To: <87k4332ipm.fsf@schwinge.name>
On 03/02/2012 02:14 PM, Thomas Schwinge wrote:
> Hi!
>
> On Fri, 2 Mar 2012 12:00:36 +0000, Pedro Alves <palves@redhat.com> wrote:
>> On 03/02/2012 11:17 AM, Thomas Schwinge wrote:
>>> On Thu, 1 Mar 2012 17:18:47 -0700, Kevin Buettner <kevinb@redhat.com> wrote:
>>>>> On Thu, 01 Mar 2012 10:00:00 +0100
>>>>> Thomas Schwinge <thomas@codesourcery.com> 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
next prev parent reply other threads:[~2012-03-06 19:08 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-15 14:00 Thomas Schwinge
2012-02-15 14:54 ` Pedro Alves
2012-02-16 15:27 ` [PATCH] [SH] GDB crash in sh_is_renesas_calling_convention, TYPE_CALLING_CONVENTION (was: Prologue skipping if there is none) Thomas Schwinge
2012-02-16 19:38 ` [PATCH] [SH] GDB crash in sh_is_renesas_calling_convention, TYPE_CALLING_CONVENTION Tom Tromey
2012-02-15 16:09 ` [PATCH] [SH] Prologue skipping if there is none Kevin Buettner
2012-02-16 0:13 ` Kevin Buettner
2012-02-16 16:59 ` Thomas Schwinge
2012-02-17 2:30 ` Kevin Buettner
2012-02-20 16:19 ` Thomas Schwinge
2012-02-21 5:25 ` Kevin Buettner
2012-02-24 11:09 ` Thomas Schwinge
2012-02-24 22:21 ` Kevin Buettner
2012-02-29 13:51 ` Thomas Schwinge
2012-03-01 0:13 ` Kevin Buettner
2012-03-01 9:03 ` Thomas Schwinge
2012-03-01 9:00 ` Thomas Schwinge
2012-03-02 0:19 ` Kevin Buettner
2012-03-02 11:18 ` Thomas Schwinge
2012-03-02 12:01 ` Pedro Alves
2012-03-02 14:15 ` Thomas Schwinge
2012-03-06 19:08 ` Pedro Alves [this message]
2012-03-03 1:18 ` Kevin Buettner
2012-03-05 15:16 ` Thomas Schwinge
2012-03-05 19:40 ` Kevin Buettner
2012-02-21 15:23 ` Thomas Schwinge
2012-02-22 14:54 ` Simulator testing for sh and sh64 (was: [PATCH] [SH] Prologue skipping if there is none) Thomas Schwinge
2012-02-22 16:56 ` Kevin Buettner
2012-02-22 19:33 ` Simulator testing for sh and sh64 Thomas Schwinge
2012-02-23 0:35 ` Kaz Kojima
2012-02-24 21:38 ` Thomas Schwinge
2012-02-23 19:55 ` Thomas Schwinge
2012-02-23 22:53 ` Kevin Buettner
2012-02-24 11:12 ` Thomas Schwinge
2012-02-23 23:57 ` Kevin Buettner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F564F92.8060100@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=kevinb@redhat.com \
--cc=thomas@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox