Message ID | 20170901180029.9527-1-hjl.tools@gmail.com |
---|---|
Headers | show |
Series | Hide internal functions in libc.so | expand |
On 09/01/2017 07:59 PM, H.J. Lu wrote: > On x86, > > # readelf -rW libc_pic.a | grep " __" | grep PLT32 | awk '{ print $5 }' | sort | uniq > > shows that many internal functions are called via PLT in libc.so. This > series of patches hides internal functions to allow direct access within > libc.so and libc.a without using GOT nor PLT. I think we need to automate the generation of hidden attributes (or the hidden aliases). Any ideas how we can do this? Thanks, Florian
On Fri, Sep 1, 2017 at 11:16 AM, Florian Weimer <fweimer@redhat.com> wrote: > On 09/01/2017 07:59 PM, H.J. Lu wrote: >> On x86, >> >> # readelf -rW libc_pic.a | grep " __" | grep PLT32 | awk '{ print $5 }' | sort | uniq >> >> shows that many internal functions are called via PLT in libc.so. This >> series of patches hides internal functions to allow direct access within >> libc.so and libc.a without using GOT nor PLT. > > I think we need to automate the generation of hidden attributes (or the > hidden aliases). I'd love to see it. > Any ideas how we can do this? > It won't be easy.
On Fri, 1 Sep 2017, Florian Weimer wrote: > On 09/01/2017 07:59 PM, H.J. Lu wrote: > > On x86, > > > > # readelf -rW libc_pic.a | grep " __" | grep PLT32 | awk '{ print $5 }' | sort | uniq > > > > shows that many internal functions are called via PLT in libc.so. This > > series of patches hides internal functions to allow direct access within > > libc.so and libc.a without using GOT nor PLT. > > I think we need to automate the generation of hidden attributes (or the > hidden aliases). I'm not convinced, for the present patch series. An internal function needs to be declared somewhere anyway, with or without an explicit hidden attribute, so putting the attribute there when declaring the function doesn't really complicate things. (I do think that if the attributes are explicit, there should also be a test that any external symbol in an object going into a shared library, that doesn't end up as a (defined or undefined) dynamic symbol in that shared library, is hidden, so that adding a non-hidden internal function is immediately visible as a test failure.) > Any ideas how we can do this? Well, an alternative to marking internal functions hidden would be to mark exported functions (mostly but not entirely declared in the public headers) as exported, and then build with -fvisibility=hidden. But that's still a lot of declarations in source files. Maybe for each public header you could compile an include of it with -D_GNU_SOURCE -aux-info to get a list of functions (like conform/GlibcConform.pm does) and automatically generate a header with a series of extern __typeof (foo) foo __attribute__ ((__visibility__ ("default"))); declarations. (Note -aux-info only covers functions, not variables, and the exported names may not always be the ones declared in the header. The Versions files would be another source of information on what should be exported.) Now, currently getting a list of all public headers requires recursing into each build subdirectory and doing something like the above would require such recursing before any of the rest of the build could start - and recursing into each subdirectory is serialized, and comparatively slow. If it were helpful we could e.g. decide to put all public headers either in an include-public directory, or in sysdeps directories, so e.g. include-public/stdlib.h instead of stdlib/stdlib.h.
On 09/01/2017 10:14 PM, Joseph Myers wrote: > On Fri, 1 Sep 2017, Florian Weimer wrote: > >> On 09/01/2017 07:59 PM, H.J. Lu wrote: >>> On x86, >>> >>> # readelf -rW libc_pic.a | grep " __" | grep PLT32 | awk '{ print $5 }' | sort | uniq >>> >>> shows that many internal functions are called via PLT in libc.so. This >>> series of patches hides internal functions to allow direct access within >>> libc.so and libc.a without using GOT nor PLT. >> I think we need to automate the generation of hidden attributes (or the >> hidden aliases). > I'm not convinced, for the present patch series. An internal function > needs to be declared somewhere anyway, with or without an explicit hidden > attribute, so putting the attribute there when declaring the function > doesn't really complicate things. (I do think that if the attributes are > explicit, there should also be a test that any external symbol in an > object going into a shared library, that doesn't end up as a (defined or > undefined) dynamic symbol in that shared library, is hidden, so that > adding a non-hidden internal function is immediately visible as a test > failure.) I was concerned about cross-architecture variance in this area. But I presume we can just add a hidden alias and add the export to the relevant sysdeps Versions files, so that's not an actual blocker for explicit specification of visibility. So the main issue here is testing that we do not regression in the coverage of hidden declarations. Thanks, Florian