Re: -fPIE and stuff
Sune Vuorela <nospam@vuorela.dk> writes:
> One of my upstreams of a collection of shared libraries is about to make
> a change that is going to require all executables built against these
> shared libraries to be built with -fPIE (and libraries with -fPIC).
> Is there anything I should be aware of?
First, the bit that you already know, but saying it for the record here:
Libraries with -fPIC is, of course, already expected. There are only a
few exceptions for speed reasons on register-constrained architectures.
I'd generally say that if the library isn't so performance-critical that
the maintainers consider reimplementing parts of it in hand-coded
assembly, just always use -fPIC.
For PIE, the main practical problem with PIE is that PIE and PIC conflict,
so you can't just add -fPIE to the compiler flags of a package that builds
both executables and libraries. That's the only reason why I'm not now
building all of my binaries PIE. So I think there's no problem with just
going along with upstream on this change; more and more of the archive is
going to be built PIE anyway as hardening flags slowly make their way into
our packages.
Both consume a register on i386, which is a problem because i386 is
ridiculously register-constrained. But it's not a significant issue on
amd64, which the trend lines all say is the direction everything is going
anyway.
Debian doesn't currently do prelinking; Red Hat does (optionally), and
it's extremely annoying for intrusion detection software like Tripwire,
since the prelinking goes through and changes installed files and now the
checksums don't match. That's the main reason why I'm not sure prelinking
is worth it; I'll take the speed hit from using non-prelinked binaries in
exchange for verifiable checksums. (Of course, it would be great to have
both.)
> A bit of background:
> http://www.macieira.org/blog/2012/01/sorry-state-of-dynamic-libraries-on-linux/
> http://www.macieira.org/blog/2012/01/update-and-benchmark-on-the-dynamic-library-proposals/
These are excellent, and a good companion to Ulrich Drepper's paper (also
linked there). They go over good C shared library behavior; some of those
techniques (like hidden visibility for internal symbols and -Bsymbolic)
I've been using for some of my shared libraries for years now.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: