Hi, Find attached a patch with some fixes to The Gentoo Hardened Toolchain Guide (/proj/en/hardened/hardened-toolchain.xml), in case you want to take them into account.
Regards.
Index: hardened-toolchain.xml =================================================================== RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/hardened-toolchain.xml,v retrieving revision 1.5 diff -u -B -u -r1.5 hardened-toolchain.xml --- hardened-toolchain.xml 31 Aug 2006 16:49:11 -0000 1.5 +++ hardened-toolchain.xml 3 Jun 2012 21:16:58 -0000 @@ -1,7 +1,8 @@ <?xml version="1.0" encoding="UTF-8"?> +<!-- $Header: $ --> <!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> -<guide link="/proj/en/hardened/hardened-toolchain.xml" lang="en" disclaimer="draft"> +<guide lang="en" disclaimer="draft"> <title>The Gentoo Hardened Toolchain</title> <author title="Author"> @@ -200,10 +201,10 @@ </p> <ul><li>Symbol visibility support, which when used properly, reduces dramatically the number of symbols to resolve and hence the amount of time taken to resolve them</li> <li>Hash tables, which will be generated by the linker and included as a extra section in the ELF file, which make looking up symbols to resolve them nearly free.</li> -<li>Direct binding, which simplifies the search that the loader by incorporating information in each library detailing exactly where the symbol to be resolved is located.</li> +<li>Direct binding, which simplifies the search that the loader has to perform by incorporating information in each library detailing exactly where the symbol to be resolved is located.</li> </ul> <p> -See <uri link="#NOWissues">Issues arising from BIND_NOW</uri> for more. +See <uri link="#NOWissues">Issues arising from default NOW</uri> for more. </p> </body> </section> @@ -276,7 +277,7 @@ However if an ebuild creates both executables and libraries then more detailed modifications need to be made, to add the -fno-PIE to the compilation of objects destined for the libraries. Where an object is used for both a shared library and an executable, it is necessary to modify the build process significantly in order to obtain two objects, one built -fPIC and one built -fPIE for linking to the library and the executable respectively. Most packages that provide both a shared library and a static archive do so by using libtool which does the right thing automatically. Both of these approaches can be taken unconditionally; i.e. it is not necessary to make such changes conditional on the presence of the hardened compiler. </p> <p> -Occasionally application code will fail to compile with -fPIE. If this happens it is usually down to non-position-independent assembler code, and is most prevelant on X86 which has a limited general purpose register set. However this is rare in application code as normally application authors push most of their code into shared libraries, although it does happen. Most position-independent build problems occur in shared libraries which are not built position-independent - this is a problem regardless of Hardened, and is nothing to do with PIE; it is just that the issue is highlighted by the hardened compiler due to the automatic enabling of -fPIE when -fPIC is not specified as described above. See the <uri link="/proj/en/hardened/pic-fix-guide.xml">PIC fixing guide</uri> for information on how to fix this sort of problem. +Occasionally application code will fail to compile with -fPIE. If this happens it is usually down to non-position-independent assembler code, and is most prevalent on X86 which has a limited general purpose register set. However this is rare in application code as normally application authors push most of their code into shared libraries, although it does happen. Most position-independent build problems occur in shared libraries which are not built position-independent - this is a problem regardless of Hardened, and is nothing to do with PIE; it is just that the issue is highlighted by the hardened compiler due to the automatic enabling of -fPIE when -fPIC is not specified as described above. See the <uri link="/proj/en/hardened/pic-fix-guide.xml">PIC fixing guide</uri> for information on how to fix this sort of problem. </p> <p> Some applications have been reported to segfault when built as PIEs. Exactly why this occurs is unclear, but it is likely due to a compiler bug so later compiler versions may resolve such problems. @@ -393,7 +394,7 @@ NOW binding has several noticeable effects. The first is that initial loading time for applications increases, sometimes very noticeably, as the loader resolves all the references before passing execution to the loaded process. </p> <p> -One technology that could reduce this overhead significantly is the introduction of "Direct Binding", something that exists on Unix systems (e.g. Solaris) but does not exist in the GNU toolchain. Direct binding adds information to libraries when they are built, to tell the linker which library contains the symbol it is looking for. Normally the linker performs a search across all referenced libraries to find symbols, which adds significantly to the time taken to resolve them. However the implications of direct-binding are significant, and cannot be taken lightly. Michael Meeks at Novell is working on this; see our <uri link="http://bugs.gentoo.org/114008";>bug #114008</uri> for our status on this. +One technology that could reduce this overhead significantly is the introduction of "Direct Binding", something that exists on Unix systems (e.g. Solaris) but does not exist in the GNU toolchain. Direct binding adds information to libraries when they are built, to tell the linker which library contains the symbol it is looking for. Normally the linker performs a search across all referenced libraries to find symbols, which affects significantly to the time taken to resolve them. However the implications of direct-binding are significant, and cannot be taken lightly. Michael Meeks at Novell is working on this; see our <uri link="http://bugs.gentoo.org/114008";>bug #114008</uri> for our status on this. </p> <p> Other technologies which should help are symbol visibility and hash tables in the ELF files. Both are technologies supported upstream, so when they appear they will be supported directly. With these two together, it is likely that there will not be much further benefit from direct binding and the complications that arise from direct binding may mean it won't be supported.
pgpBZD3ESDbqj.pgp
Description: PGP signature
