Re: [gentoo-hardened] Re: [gentoo-embedded] hardened gcc-3.3.2 anduClibc

[Peter S. Mazinger]

On Thu, 20 Nov 2003, Alexander Gabert wrote:

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

> > > > 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.
I have removed interp.o from gcc's specs and it really works (I had 
earlier 2 references for /lib/ld-uClibc.so.0 (strings binary) in the 
binary, now only one, thanks. Now the only change is Scrt1.o->crt1S.o. 
Probably it would be better to install the PaX version as Scrt1.o in 
uClibc, so I'll make a change to the uClibc patches, then no speciality is 
needed for hardened-gcc to support uClibc as well.

> > > > 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.
The versions >= 2.14.90.0.6 support -pie, so it would be enough to define 
.6 as minimal requirement (but hardened-gcc requires > .7-r3, this was 
really the question).
Well, probably I have to check it myself. I loose the function 
__fixunsxfdi from libgcc if gcc is rebuilt a second time in an uClibc 
buildroot environment, and I didn't find the cause until now (needed by 
coreutils-5.x)

> 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 have problems related to pie with gzip-1.3.3 and 1.3.5. Now, you where 
right, the ./configure ANSI header detection works (does not segfault), 
since I changed from -shared to -pie, but the executable is unusable.

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

Thanks for your explanations,

Peter

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


____________________________________________________________________
Miert fizetsz az internetert? Korlatlan, ingyenes internet hozzaferes a FreeStarttol.
Probald ki most! http://www.freestart.hu

--
gentoo-hardened@g.o mailing list