This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH V7] amd64-mpx: initialize bnd register before performing inferior calls.
On 02/08/2017 01:27 PM, Pedro Alves wrote:
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.
At this point i think it is woth to mention a bit more on the usage
model I had in mind.
At the inferior call time all BND registers are set to the INIT state.
That covers 90% of the usage case and keeps the actual behavior of GDB.
In case it is desirable to investigate any bound violation user can add
a breakpoint on the prolog of the function and
set the BND register there, I understand that this is the normal use
case for the debugger as well.
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:
ABI defines which BND is used for which parameter and what to do when it
is needed to pass more bounds than BND registers available.
(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 ?
Yes we would need to set the BND in GDB in this scenario.
However we could simply let that attribution to the user.
My point of view is that this could complicate a lot the code to cover
very little use.
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.
I was also considering this model as my first implementation.
But this way I suppose that it will be even more complicated.
We will need special commands for the architecture, special documentation...
if we set afterwards: Inferior call + Break point + register set.
we should not need any additional set and show for the architecture.
Hover as you pointed out in the other e-mail it is better to increase
testing and document it.
Thanks,
Pedro Alves
Thanks a lot for your review!
/Fred
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928