diff options
Diffstat (limited to 'hardened/toolchain/branches/pieworld/toolchain.README')
| -rw-r--r-- | hardened/toolchain/branches/pieworld/toolchain.README | 154 |
1 files changed, 0 insertions, 154 deletions
diff --git a/hardened/toolchain/branches/pieworld/toolchain.README b/hardened/toolchain/branches/pieworld/toolchain.README deleted file mode 100644 index 6e65198..0000000 --- a/hardened/toolchain/branches/pieworld/toolchain.README +++ /dev/null @@ -1,154 +0,0 @@ -NOTES -===== - -Non-PIE support is a mess (well, strictly speaking it's broken) -So far, crt{begin,end}.o are now correctly built no-PIE. -However, libgcc.a/libgcc_eh.a, libc.a, libpthread.a, libieee.a, libgcov.a -are built PIE. This ok for linking PIEs, but rubbish for doing non-PIE -links (i.e. vanilla). Also crtfastmath.o is only built once (there's no -crtfastmathS.o) - so we build it PIE. - -So, what to do? - -For vanilla compiles, we need the .a's built -nopie. -For hardened compiles, we need the .a's built -fPIE - if they ever get used -that way. If we can convince ourselves that when building -fPIE the .so's -are used, then we don't need PIE versions of these .a's. -To do this, add '-nopie' to CFLAGS for libgcc.a in gcc/Makefile.in? - -For libc.a - we could treat hardened as a multilib system; with the normal no-PIE -ABI and our PIE ABI - and get glibc to build itself two ways; one for vanilla and -one for hardened. Or, we could try to force all .a's to be built -nopie - this -isn't easy, however, as you can't tell from normal compilation commands whether -it's for a .a or for an executable. - -I think the multiple-ABI approach is easier. We could then drop PIE from the -compiler variants, leaving just relro/now and ssp combinations, which don't change -the ABI, and do the -fPIE thing in the compiler wrapper, when ABI is PIE. -I'm thinking of doing MULTLIB_ABIS="x86 x86_pie" and defining -CFLAGS_x86_pie="-fpie -pie" -LDFLAGS_x86_pie="-fpie -pie" -LIBDIR_x86="lib" -LIBDIR_x86_pie="libpie" -note; the gcc-config wrapper adds CFLAGS_x86_pie to the command line, but doesn't look at LDFLAGS_<abi> - - -Upgrade path for Hardened Gentoo users from glibc-2.3*/gcc-3* to glibc-2.4+/gcc-4.1+ -==================================================================================== - -Note; references to "hardened", "non-hardened" etc refer to the toolchain, not the -kernel. - - -Generic upgrade instructions ----------------------------- - -There are separate instructions depending on where you start. Instruction set (2) -should work in all cases, provided a vanilla compiler is set via gcc-config first. -However the most common case will be (1) - which is why it's listed first :) - - -1) HARDENED SYSTEMS with hardened gcc-3 and glibc-2.3 - Going from an existing hardened system (gcc-3.4.6 & glibc-2.3.6 hardened) - - .1) emerge --oneshot sys-libs/glibc - build the hardened version of glibc-2.4 (with the gcc-3 hardened compiler) - - .2) emerge --oneshot sys-devel/gcc - build the hardened gcc-4.1.1 with the hardened gcc-3.4.6 - - .3) emerge --oneshot sys-libs/glibc - rebuild the hardened version of glibc-2.4 (with the gcc-4 hardened compiler) - - -2) NON-HARDENED SYSTEMS with gcc-4.1.1 and glibc-2.4 (no -hardened compiler available) - Going from non-hardened stage3 2006.1: - This starts from non-hardened gcc-4.1.1 and glibc-2.4 - - .1) Switch profile to the hardened profile - This means remaking the softlink /etc/make.conf to a hardened profile. - Do not confuse this with selecting a hardened compiler with gcc-config (which - you can't do anyway from the standard 2006.1 stage3). - - .2) emerge --oneshot sys-libs/glibc - Build glibc with support for both gcc-3 and gcc-4 stack protectiona. - - .3) USE="-hardened" emerge --oneshot sys-devel/gcc - Build gcc-4 non-hardened, but including split-specs so it can build - hardened objects later. - - .4) gcc-config to the (now available) hardened variant of the compiler. - - .5) emerge --oneshot sys-libs/glibc - Build the hardened version of glibc-2.4 (with the gcc-4 hardened compiler) - - .6) emerge --oneshot sys-devel/gcc - This will build gcc itself hardened (in particular, building the static libraries PIE) - - -3) NON-HARDENED SYSTEMS with a -hardened gcc available - - .1) gcc-config to the -hardened gcc - - .2) emerge --oneshot sys-libs/glibc - Build glibc with support for both gcc-3 and gcc-4 stack protectiona. - - .3) emerge --oneshot sys-devel/gcc - build the hardened gcc-4.1.1 with a hardened gcc - - .4) emerge --oneshot sys-libs/glibc - rebuild the hardened version of glibc-2.4 (with the gcc-4 hardened compiler) - - -Platform-specific notes ------------------------ - -sparc -For gcc-4 SSP to work, glibc must be 2.4 or higher. Glibc-2.4 is nptl-only, so this means -it's not available on 32-bit sparc (sparcv8). - - - - -Toolchain mods for hardened gcc-4.x/glibc-2.4 -============================================= - -* glibc __stack_chk_fail implementation written so that it's ok when glibc built with SSP - Implement stderr & syslog messaging, SIGKILL and _exit to provide a secure termination - (the one supplied by glibc is for debug purposes only), and all via inline syscalls - avoiding any function calls (which would potentially invoke __stack_chk_fail). - Note; building glibc with ssp-all is causing too many problems at the moment, so for - now it's set to build without ssp. - Sorted out the PIE building better (replaces the filter-ldflags -pie with something - more sensible). - (done) Use SIG_ABRT instead of SIG_KILL - means doing the sigset stuff. - (done) Use INTERNAL_SYSCALL (check vsyscall page isn't user modifiable) - -* gcc minispecs for gcc-4.1.1 and gcc-3.4.6, from psm - Much simplified gcc patching for hardened compiler; use of minispecs to generate - the relevant specs files. Involves a few changes in toolchain.eclass and - flag-o-matic.eclass. - -* Specs switching handled by the wrappers, rather than the gcc-specs-env patch - (app-admin/eselect-compiler only). This gives us ccache reliability, as for - gcc itself the specs are specified on the command line as normal. - May not be a good idea - doing it gcc itself guarantees it'll happen even if - the wrappers aren't used (is that ever the case?). - Further investigation ongoing to manage filtering; considering doing this by - adjusting GCC_SPECS, although it may be better as a separate variable (perhaps - as part of COMPILER_FEATURES - see bug #128810) - -Still cooking - -* Look into -DFORTIFY_SOURCE=2, -msecure-plt for ppc - - -Status summary: -=============== - -glibc ok (builds itself non-ssp) -gcc ok (ish) - Needs distfile gcc-4.1.1-piepatches-v9.0.6.tar.bz2 from toolchain/distfiles - (or gcc-3.4.6-piepatches-v9.0.5.tar.bz2 for gcc-3.4.6) - - |