Re: Hidden PLT workaround

[Ryan Arnold <ryan dot arnold at gmail dot com>]

On Wed, May 12, 2010 at 8:37 PM, Boris Arnoux <boris.arnoux@gmail.com> wrote:
> Hello,
>
> ÂFor the record, and those who might need it, I implemented a few
> scripts to patch glibc automatically.
> It takes a given set of symbols from a file, for example system calls, and
> does the necessary replacements into the Versions and source code files.
>
> ÂIt does not make many assumptions about the code itself, so it should work on
> other glibc versions. I successfully tested it on 2.11.1.
>
> ÂPlease feel free to test :
> http://hackswitch.blogspot.com/2010/05/return-of-plt.html
>
> ( see the bottom of the page for the sourceforge page )

Hi Boris,

I read your blog post.  I'd just like to clarify that there are
several reasons why the visibility/mutability of the internal
functions have been restricted.  Functions which support 'hooks' have
exported function interfaces already and libc itself will go through
the PLT for these cases.  This is described a little bit further here:

http://sources.redhat.com/glibc/wiki/Testing/Check-localplt

Here are some of the reasons why GLIBC uses hidden internal symbols
inside of itself for all but the designated hooks or multi-lib code
paths:

1.) Debugging.. If you've overridden internal symbols the libc
maintainer and volunteers can't be sure whether your changes to
internal symbols have caused the problems you're seeing.  This is a
big deal for Linux distro maintainers since bug fixing is expensive
and time consuming.

2.) Performance:  Certain architectures experience reduced performance
from using the PLT versus direct branches using hidden internal
symbols.  If the symbol isn't in a library, and it isn't a hook or
multi-lib code-path (STT_GNU_IFUNC) then one can just use a direct
branch to the functions to save on performance.  One can also force
the linker to fixup PLT calls into direct branches if compiling with
-Bsymbolic but I'm not sure if this works for GLIBC.

3.) Security:

There may be other reasons as well.

Regards,
Ryan S. Arnold