[gentoo-hardened] Re: __guard and __stack_smash_handler transition from libgcc to libc

[Peter S. Mazinger]

On Sun, 23 Nov 2003, Alexander Gabert wrote:

> hi Martin,
>
> sorry to disturb you but there has been a hot weekend with me sorting
> out the side effects of the glibc transition to guard symbols.
>
> As this is becoming a technical challenge, i will explain it because i
> am sure we are on the right path with
> http://bugs.gentoo.org/show_bug.cgi?id=25299 containing a gcc ebuild
> diff which can do it right if bootstrap.sh on stage1 installations goes
> for building gcc directly after glibc (seemant told me this is a simple
> change).
>
> If the existing glibc is to be found to have the functions and the
> object of propolice inserted, the ebuild needs to search for binaries
> containing references to the __guard@GCC Version symbol in the shared
> library libgcc.so before removing the object and the functions in the
> gcc libgcc.
>
> My personal thanks go to swtaylor for finding this issue with his
> machine and reporting back with helping me sort out the troublemaker.
>
> As seen in the bugs and from my personal experiences with hacking a
> crt1.o based __guard version that would have no issues with -nostdlib i
> think it would not be worth the effort because the ebuilds filter
> -fstack-protector when -nostdlib is used, hardened-gcc is also on a safe
> path and last but not least we could use a gcc specs modification at the
> gcc source level to also prevent this kind of happening.
>
> What is left to the propolice author is to solve the problems and
> Internal Compiler Errors with C++ code that are still showing up with
> recent gcc versions and ebuilds like OpenOffice as far as i can tell but
> this is not related to our job here moving around and improving the
> infrastructure of the functions exposed to the userland.
>
> The penalty of an additional copy relocation being used as a __guard
> location for nonPIC binaries (instead of the glibc @GOT memory location
> that would normally being used when a corresponding PIC dynamically
> linked etdyn binary is started together with it's shared libraries) with
> the guard loaded and initialized in the .BSS segment as @GOT-copy and
> shared libraries also using this .BSS copy and also initialized by
> __guard_setup in glibc is not affecting the proper operation of apache2
> -D PHP4 which is in my experiences a test case for the correct behaviour
> of hardened-gcc because it failed with the previous behaviour of the php
> library loading and writing "opposite" __guard canary setups over cross
> :-)
>
> Please approve and submit my changes in
> http://dev.gentoo.org/~pappy/gentoo-x86/sys-devel/gcc/ to the
> appropriate ebuilds of gcc and report back any improvements you would
> like to see in the progress of this movement.
Is it possible to get these files also as a non-dev (now access is
prohibited)?
I would like to test it for uClibc too.

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