| 1 |
hi Martin, |
| 2 |
|
| 3 |
sorry to disturb you but there has been a hot weekend with me sorting |
| 4 |
out the side effects of the glibc transition to guard symbols. |
| 5 |
|
| 6 |
As this is becoming a technical challenge, i will explain it because i |
| 7 |
am sure we are on the right path with |
| 8 |
http://bugs.gentoo.org/show_bug.cgi?id=25299 containing a gcc ebuild |
| 9 |
diff which can do it right if bootstrap.sh on stage1 installations goes |
| 10 |
for building gcc directly after glibc (seemant told me this is a simple |
| 11 |
change). |
| 12 |
|
| 13 |
If the existing glibc is to be found to have the functions and the |
| 14 |
object of propolice inserted, the ebuild needs to search for binaries |
| 15 |
containing references to the __guard@GCC Version symbol in the shared |
| 16 |
library libgcc.so before removing the object and the functions in the |
| 17 |
gcc libgcc. |
| 18 |
|
| 19 |
My personal thanks go to swtaylor for finding this issue with his |
| 20 |
machine and reporting back with helping me sort out the troublemaker. |
| 21 |
|
| 22 |
As seen in the bugs and from my personal experiences with hacking a |
| 23 |
crt1.o based __guard version that would have no issues with -nostdlib i |
| 24 |
think it would not be worth the effort because the ebuilds filter |
| 25 |
-fstack-protector when -nostdlib is used, hardened-gcc is also on a safe |
| 26 |
path and last but not least we could use a gcc specs modification at the |
| 27 |
gcc source level to also prevent this kind of happening. |
| 28 |
|
| 29 |
What is left to the propolice author is to solve the problems and |
| 30 |
Internal Compiler Errors with C++ code that are still showing up with |
| 31 |
recent gcc versions and ebuilds like OpenOffice as far as i can tell but |
| 32 |
this is not related to our job here moving around and improving the |
| 33 |
infrastructure of the functions exposed to the userland. |
| 34 |
|
| 35 |
The penalty of an additional copy relocation being used as a __guard |
| 36 |
location for nonPIC binaries (instead of the glibc @GOT memory location |
| 37 |
that would normally being used when a corresponding PIC dynamically |
| 38 |
linked etdyn binary is started together with it's shared libraries) with |
| 39 |
the guard loaded and initialized in the .BSS segment as @GOT-copy and |
| 40 |
shared libraries also using this .BSS copy and also initialized by |
| 41 |
__guard_setup in glibc is not affecting the proper operation of apache2 |
| 42 |
-D PHP4 which is in my experiences a test case for the correct behaviour |
| 43 |
of hardened-gcc because it failed with the previous behaviour of the php |
| 44 |
library loading and writing "opposite" __guard canary setups over cross |
| 45 |
:-) |
| 46 |
|
| 47 |
Please approve and submit my changes in |
| 48 |
http://dev.gentoo.org/~pappy/gentoo-x86/sys-devel/gcc/ to the |
| 49 |
appropriate ebuilds of gcc and report back any improvements you would |
| 50 |
like to see in the progress of this movement. |
| 51 |
|
| 52 |
Thanks for your help, |
| 53 |
|
| 54 |
Alex |
| 55 |
|
| 56 |
|
| 57 |
-- |
| 58 |
gentoo-hardened@g.o mailing list |
Archives