PowerPC SecurePLT - stepping into library function

PowerPC SecurePLT - stepping into library function

[Michael Eager]

GDB doesn't step into functions in a shared library
on PowerPC which are compiled with -msecure-PLT.  It steps
over the function like the "next" command.

It looks like GDB makes a number of assumptions based
on the original SVR4 PLT design and which are not valid
with securePLT.  One assumption is that the PLT stub is
in the .plt section.  Another is that the symbol for the
PLT stub will have an STT_ENTRY in the symtab.

It seems that the best way to fix this would be to create
a new OSABI sniffer for SecurePLT which identifies that
the executable was compiled with -msecurePLT.  One issue
is how to identify these programs.  The Power Arch 32-bit ABI
(Sect 5.2.5.2, note at end) says that these will have
R_PPC_REL16 relocations.  I don't see any of these relocs.
The .plt section is marked ALLOC CODE WRITE in non-SecurePLT
and ALLOC WRITE in SecurePLT.  Is the ABI incorrect or is
Binutils not following it?

Is there any possibility of a chimera:  an executable compiled
using Secure PLT linking to libraries which use the old style
PLT?  Or vice-versa?  I'm assuming that this cannot happen.

I can modify BFD to record whether the .plt section in the
executable was marked CODE or not, create an new OSABI sniffer
to identify a new GDB_OSABI_LINUX_SECUREPLT ABI variant, and
then write the variants of find_solib_trampoline_target(), etc.,
which are needed to recognize the PLT stubs and glink code.

I'm open to suggestions about a different approach. Is there
something which I may have overlooked?


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: PowerPC SecurePLT - stepping into library function

[Joseph S. Myers]

On Fri, 6 Jan 2012, Michael Eager wrote:

> It seems that the best way to fix this would be to create
> a new OSABI sniffer for SecurePLT which identifies that
> the executable was compiled with -msecurePLT.  One issue
> is how to identify these programs.  The Power Arch 32-bit ABI
> (Sect 5.2.5.2, note at end) says that these will have
> R_PPC_REL16 relocations.  I don't see any of these relocs.

That's about relocatable objects, i.e. static relocations in .o files, not 
dynamic relocations in executables and shared libraries.

> Is there any possibility of a chimera:  an executable compiled
> using Secure PLT linking to libraries which use the old style
> PLT?  Or vice-versa?  I'm assuming that this cannot happen.

As far as I know that ought to work.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: PowerPC SecurePLT - stepping into library function

[Mark Kettenis]

> Date: Fri, 06 Jan 2012 11:54:01 -0800
> From: Michael Eager <eager@eagerm.com>
> 
> GDB doesn't step into functions in a shared library
> on PowerPC which are compiled with -msecure-PLT.  It steps
> over the function like the "next" command.

Is the SecurePLT stuff documented somewhere?

Re: PowerPC SecurePLT - stepping into library function

[Michael Eager]

On 01/06/2012 12:15 PM, Mark Kettenis wrote:
>> Date: Fri, 06 Jan 2012 11:54:01 -0800
>> From: Michael Eager<eager@eagerm.com>
>>
>> GDB doesn't step into functions in a shared library
>> on PowerPC which are compiled with -msecure-PLT.  It steps
>> over the function like the "next" command.
>
> Is the SecurePLT stuff documented somewhere?

https://www.power.org/resources/downloads/Power-Arch-32-bit-ABI-supp-1.0-Linux.pdf

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: PowerPC SecurePLT - stepping into library function

[Michael Eager]

On 01/06/2012 12:09 PM, Joseph S. Myers wrote:
> On Fri, 6 Jan 2012, Michael Eager wrote:
>
>> It seems that the best way to fix this would be to create
>> a new OSABI sniffer for SecurePLT which identifies that
>> the executable was compiled with -msecurePLT.  One issue
>> is how to identify these programs.  The Power Arch 32-bit ABI
>> (Sect 5.2.5.2, note at end) says that these will have
>> R_PPC_REL16 relocations.  I don't see any of these relocs.
>
> That's about relocatable objects, i.e. static relocations in .o files, not
> dynamic relocations in executables and shared libraries.

I didn't see any in the .o files, either.

>> Is there any possibility of a chimera:  an executable compiled
>> using Secure PLT linking to libraries which use the old style
>> PLT?  Or vice-versa?  I'm assuming that this cannot happen.
>
> As far as I know that ought to work.

Yeah, that's what I was afraid of.  That means that an OSABI
sniffer will not work.


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: PowerPC SecurePLT - stepping into library function

[Mark Kettenis]

> Date: Fri, 06 Jan 2012 12:24:38 -0800
> From: Michael Eager <eager@eagerm.com>
> 
> https://www.power.org/resources/downloads/Power-Arch-32-bit-ABI-supp-1.0-Linux.pdf

Thanks!

I guess you'll have to do some sort of instruction pattern matching.
The ABI document suggests specific code sequences for them, which is
probably what everybody uses to implement them.  You might want to
have a look at what is done in mips-linux-tdep.c, since it seems to
have linkage stubs outside of the PLT as well.  Actually closer to
home the 64-bit PowerPC stuff seems to do somethings similar.

Re: PowerPC SecurePLT - stepping into library function

[Michael Eager]

On 01/06/2012 12:56 PM, Mark Kettenis wrote:
>> Date: Fri, 06 Jan 2012 12:24:38 -0800
>> From: Michael Eager<eager@eagerm.com>
>>
>> https://www.power.org/resources/downloads/Power-Arch-32-bit-ABI-supp-1.0-Linux.pdf
>
> Thanks!
>
> I guess you'll have to do some sort of instruction pattern matching.
> The ABI document suggests specific code sequences for them, which is
> probably what everybody uses to implement them.  You might want to
> have a look at what is done in mips-linux-tdep.c, since it seems to
> have linkage stubs outside of the PLT as well.  Actually closer to
> home the 64-bit PowerPC stuff seems to do somethings similar.

mips and ppc64 seem to do the similar tests, but in different places.

mips adds instruction pattern matching to the in_solib_dynsym_resolve()
test at infrun.c:4755 so that it succeeds, entering a block of code
which skips the symbol resolver.

ppc64 does instruction pattern matching to skip over trampoline code,
called at infrun.c:4902 but since it calls the same failing
in_solib_dynsym_resolve() a couple lines later, I don't think that it
has any effect.

Looks like doing the same as mips is the best approach.

Thanks for the pointer.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077