Re: [gentoo-hardened] Re: [gentoo-embedded] hardened gcc-3.3.2 and uClibc

[Alexander Gabert]

hi Peter,

first of all, i have been following your commitment to hardened stuff,
grsecurity and related engagements during the last months and i am
amazed by your technical skill level and expertise.

On Wed, 2003-11-19 at 12:45, Peter S. Mazinger wrote:
> On 18 Nov 2003, Ned Ludd wrote:
>
> > On Tue, 2003-11-18 at 18:57, Peter S. Mazinger wrote:
> > > Hello!
> > >
> > > I have a clean uClibc environment (not gentoo based), and inspired by
> > > hardened-gcc-3.3.2 the gcc specs file was changed to support ET_DYN
> > > binaries, the only change I have done is replacing Scrt1.o with "crt1S.o
building -pie executables emits this stuff which is normally done by
interp.o, redundant this interp.o therefore is.
> > > interp.o" (crt1S.o not yet in the uClibc tree, but in portage), due to the
> > > fact that Scrt1.o does not exist in uClibc like in glibc-2.3.2. I do not
yes, it is in a Redhat branch update of glibc-2.3.2 as far as i can tell
> > > know what the difference is between Scrt1.o from glibc and crt1S.o coming
basically there is only a small technical difference, the goal is the
same: the function _start has the job of position independent calling
the glibc function __libc_start_main with the arguments _init _fini and
main that are given as arguments to __libc_start_main  ;-)

> > > from the hardened-gcc-2.4.6 (the version for uClibc is PaX version, so
> > > similar to those in hardened-gcc-2.4.6).
> > > Could someone comment on problems regarding this change?
yo, we try to use mainstream as possible while not giving up our high
security PaX environment.
if the Scrt1.o proves good, there is no reason to use the pioneering
version of pipacs any more ;-)
In fact it should be noted that pageexec.virtualave.net introduced and
coached us to this all stuff for such a long time and i am proud that
Redhat is doing it this way also, by not telling anyone stole anything
from anybody - but we all know how to say thank you ;-)
> > ...
> >
> > > I have seen a dependency on binutils-2.14.90.0.7, but this one has some
> > > problems with uClibc (does not correctly support canadian cross-compiling,
> > > binutils-2.14.90.0.6 yes). Is it really needed, or is
> > > binutils-2.14.90.0.6-r7 enough?
you need "ld -pie" for the true compiling of etdyn. therefore you need
the high binutils.

using -shared instead is good but has issues with ./configure running of
some program suites and missing functions because this happens:
gcc -shared does transparently compile the binary as "dynamic library
executable" which means the configure tests fail this way, i type the
hardened-gcc stuff in brackets:
./configure: gcc -lfoo-library-that-i-am -lsearching-for -lin-configure
[-fPIC -shared] -o conftest -c conftest.c

which leads to the false positive that the function tested in conftest.c
gets compiled and no linker error is emitted which would normally be the
situation when the library is not there.
then the binary could not compile but fail later during Makefile because
libs are not found.

Jakub Jelinek then invented the -pie support which is a quick shot of
-shared and uses library characteristics but without leaving unresolved
symbols and functions hang around in the target binary!
the other magic stuff i can't tell you because i would violate Redhat
NDA's, *scnr* no, not really ;-)

> > >
> > > I have rebuilt about 50 packages (mainly development environment) with
cool
>
> > > these changes, but there is some strange behaviour (it is not related
> > > to the fact that everything is -fPIC built, I had this already defined
> > > earlier in my CFLAGS for almost all packages)
well, maybe the -shared bug i mentioned above?
> > > I am also interested in an Scrt1.o version for uClibc, so a changes
yeah go ahead and create one, take the crt1S.S from pipacs, it's great
and maybe we could get him to contribute some comments and explaination
too.
> > > description between the PaX and the glibc-2.3.2 implementation would be
> > > helpful.
see pipacs for this too ;-)
> >
> > <rant>
> > Quick rundown. Sctr1.S is a redhat knock off creation of PaX's ctr1S.S
> > (ie somebody probably got paid to rip it off and claim it was a redhat
> > original creation) they even fscked up the naming convention. I wont go
> > to much in detail because I would end up ranting for hours. In short
> > Scrt1 the way it gets built by redhat will most likely end up with text
> > relocations from what I understand so the PaX crt1S.S should be used and
> > preferred till such time as redhat finds a way to break that for us.
> > </rant>
> Why is then used Scrt1.o in hardened-gcc-3.3.2?
forget about the rant.
we use it for standardizing our stuff.
>
> >
> > > Why was the default -fomit-frame-pointer option removed? From my
> > > experience there are only a few packages, that are incompatible with it
> > > (mainly libraries).
solar already said that, the speed gain is almost useless compared to
the problems you might encounter and bugs getting assigned to you, so
better keep hands off that black magic ;-)
> >
> > You would have to ask the maintainer pappy@g.o about why this
> > functionality was removed. However I can say from my personal testing we
> > truly don't seem to gain any performance by trying to gain back an extra
> > register from adding -fomit-frame-pointer when -fPIC steals away the ebx
> > register, in fact I even get roughly exactly same number of instructions
> > that get executed when using those flags together. Attached is a file I
> > did this testing with.
> >
> >

thanks for corresponding and hope i have helped,

Alex


--
gentoo-hardened@g.o mailing list