Re: [gentoo-hardened] TESTING kevquinn_overlays: amd64 hardened gcc - (bugzilla is down, i hope the mails are not)

[Peter S. Mazinger]

On Mon, 18 Dec 2006, Kevin F. Quinn wrote:

> On Mon, 18 Dec 2006 11:55:31 +0100 (CET)
> "Peter S. Mazinger" <ps.m@×××.net> wrote:
>
> > On Tue, 12 Dec 2006, Alexander Gabert wrote:
> >
> > > Kevin: this is the build failures, i would have made them end up
> > > adding into bugzilla but one of us both wasn't awake.
> > >
> > > PSM: if you're reading up: i don't have a clue.
> > >
> > > In the meantime, working with bugs.g.o. it's getting a real hassle,
> > > so can someone please kick that pos in the shins so we can work on
> > > bugs again?  TIA
> > >
> > > I think we should have a talk or two and maybe a test case for
> > > building that libiberty on all arches with either PIC or PIE code.
> > > I honestly don't care howe we build it, i just want it to work on
> > > all Gentoo supported arches for hardened.
> > >
> > > For those of you having issues with the file: here is the log for
> > > pitr and miranda:
> > >
> > > http://dev.gentoo.org/~pappy/tmp/amd64-pie-libiberty-failure.txt
> >
> > It seems some of you are mixing up PIC and PIE. For the record, there
> > are no PIE libraries and if you want to run a hardened box where each
> > file is text relocation free, then you have to compile all code that
> > goes to libraries (even into lib*.a) with -fPIC|-fpic. To quickly
> > check this statement, compile some object with -fPIE, put into libx.a
> > and compile a shared lib with -fPIC using code from libx.a. readelf
> > -d shared_lib | grep TEXTREL.
>
> Agreed - however lib*.a are not generally used to build shared
> libraries; they're mostly for building static binaries.  Gcc deals
> with libiberty (normally) by building a pic version (libiberty_pic.a)
> for linking to shared libraries when it needs to.  We do mess that up,
> I think - I'm still looking into that.

we do not mess it up, libiberty_pic.a is not used to compile the 
intermediate gen* binaries and if the build specs defaults to PIE 
binaries and then these binaries have text relocations, thus failing on a 
PaX box if the text relocations are blocked (or it is an uClibc hardened 
box, where libc blocks text relocations as well)

> > The pie patches compile everything with -fPIE unless -fPIC was used,
> > the app itself has to take care (and most apps using libtool do it by
> > using -fPIC -DPIC) that code that goes into libs is -fPIC compiled.
> > libtool fails only in cases where configure does not recognize
> > correctly the target (thats why gnuconfig_update/libtoolize are
> > needed).
> >
> > Some will argue, that it does not make sense to compile code in
> > lib*.a with -fPIC. Those shouldn't use hardened, because they end up
> > with text relocations and a hardened box should block text
> > relocations either in kernel (PaX feature) or libc (possible with
> > uClibc, but not glibc)
>
> I think it's more complicated than that.  What should go into a lib*.a
> archive depends on how it's going to be used.  If it's going to be used
> to build a shared library, then as you say the code needs to be PIC -
> however this is rare (examples are libc_*nonshared.a).  If it's being
> used to build a non-PIE executable - which usually means building a
> static executable - then the code needs to be normal (non-PIC).  If
> it's going to be used to build a (PIE) executable, the code needs to be
> PIE - in practice this is very rare, since linking to lib*.a instead
> of lib*.so means building static binaries, and that's not sensible
> when building PIEs as by definition they need the dynamic loader.

No, the code needs to be PIC, else the generated PIE binary has text 
relocation (PIE binary is more like a shared library needing though an 
interpreter/dynamic loader)

> Strictly speaking, on a hardened system, the -vanilla and -hardenednopie
> compiler cannot be guaranteed to generate working executables - indeed
> it creates garbage on sparc (x86 seems to be more forgiving; you can mix
> PIE objects into a non-PIE executable and they appear to work).

because lib*.a has to be PIC.

> I'm working on a sane solution to this problem using ABIs, but it's
> quite involved, and it's quite a departure from what we currently do.
> Once I have my thoughts clear, I'll post a proposal.
>
> For the moment, however, we can continue as we did before, but
> highlight that -vanilla and -hardenednopie may not generate working
> executables. Mostly this affects bootloaders, and things like
> static busybox.

Wondering why you mention static binaries, I have no problem on a clean 
hardened box with static binaries, even if the lib*.a are PIC 
compiled (mine are for sure, and most of you have it too, if an app is 
using autotools and running ./configure shows that the system supports 
shared libraries and for "dependant libraries" it says "pass_all"), I 
though agree that it is overkill for static binaries to use libraries 
that were PIC compiled.

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

-- 
gentoo-hardened@g.o mailing list