public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: "Tedeschi, Walfred" <walfred.tedeschi@intel.com>,
	qiyaoltc@gmail.com,        brobecker@adacore.com
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH V7] amd64-mpx: initialize bnd register before performing inferior calls.
Date: Wed, 08 Feb 2017 12:27:00 -0000	[thread overview]
Message-ID: <88c7180f-8843-a148-425a-2adf56c6d0bf@redhat.com> (raw)
In-Reply-To: <217a8c13-b7d0-7fe6-56b5-85ff53ce097a@intel.com>

On 02/07/2017 08:56 AM, Tedeschi, Walfred wrote:
> On 01/31/2017 03:13 PM, Walfred Tedeschi wrote:
>>> This patch initializes the bnd registers before executing the inferior
>>> call.  BND registers can be in arbitrary values at the moment of the
>>> inferior call.  In case the function being called uses as part of the
>>> parameters bnd register, e.g. when passing a pointer as parameter, the
>>> current value of the register will be used.  This can cause boundary
>>> violations that are not due to a real bug or even desired by the user.
>>> In this sense the best to be done is set the bnd registers to allow
>>> access to the whole memory, i.e. initialized state, before pushing the
>>> inferior call.
>> This explains the reason for clearing better ...
> Yes, it was my intention. Do you see value to have the patch in then?

I think I do.

For passing local pointers to some function, it might be
that GDB could be able to figure out which bound registers
contains the bound for a given variable, or if spilled, where
to find then, and set up the call to use the right bounds, but
I have no idea of how to retrieve that information.  I suspect
that it's not a mapping we could retrieve from the dwarf?  And
then there's also the case of passing pointers to global
variables, and pointers to memory that gdb malloc's into the
inferior, like for array/string coercion:

(gdb) p strlen ("hello")

this will alloc a block of memory in the inferior for
"hello", by calling malloc in the inferior.  If strlen
is compiled to do BND checks, would we need to setup the
BND registers to the range of the pointer returned by malloc ?

I've not used BND myself, so I don't have any experience
with it.  But my impression is that disabling BND for
infcalls makes infcalls work again on BND-enabled systems, and
that we could perhaps try to do something smart to re-enable it
in some infcall cases, if there's sufficient benefit.

Now, a question is: could this auto-clearing of BND registers
get in the way of some use cases?  E.g., could a user want to poke
at the BND registers manually before calling a function in the
inferior, in order to debug BND-related code.
If so, that may call for a new option users could tweak
if necessary.

Thanks,
Pedro Alves

  reply	other threads:[~2017-02-08 12:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-31 15:13 Walfred Tedeschi
2017-02-06 17:05 ` [ping] " Tedeschi, Walfred
2017-02-06 17:58 ` Pedro Alves
2017-02-07  8:56   ` Tedeschi, Walfred
2017-02-08 12:27     ` Pedro Alves [this message]
2017-02-08 16:21       ` Pedro Alves
2017-02-08 16:31         ` Tedeschi, Walfred
2017-02-13  8:33       ` Tedeschi, Walfred
2017-02-13 12:03         ` Pedro Alves
2017-02-13 12:55           ` Tedeschi, Walfred
2017-02-14 13:35         ` Tedeschi, Walfred
2017-02-14 13:59           ` Pedro Alves
2017-02-15 13:02             ` Tedeschi, Walfred
2017-02-15 13:15               ` Pedro Alves
2017-02-16 13:50                 ` Tedeschi, Walfred
2017-02-16 14:52                   ` Pedro Alves
2017-02-16 15:37                     ` Tedeschi, Walfred
2017-02-16 16:15                       ` Pedro Alves
2017-02-16 16:41                         ` Tedeschi, Walfred

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=88c7180f-8843-a148-425a-2adf56c6d0bf@redhat.com \
    --to=palves@redhat.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=qiyaoltc@gmail.com \
    --cc=walfred.tedeschi@intel.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).