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

[Kevin F. Quinn]

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.

> 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.

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).

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.

-- 
Kevin F. Quinn