adding support for hardened toolchain

Johannes Stezenbach
Thu Jan 6 14:04:00 GMT 2011

Hello Heiko,

On Thu, Dec 30, 2010 at 08:20:22AM -0600, Heiko Zuerker wrote:
> The hardened toolchain is not anything folks would look at on their
> own usually. Adding it to ct-ng would give it more exposure and more
> folks may tend to try it out. We really need to get to a place where
> things get more secure for everybody.

I agree on that, and thank you for bringing up this issue.;a=tree;f=target/Devil-Linux/default/patches.ct-ng/gcc/4.4.5;h=4f163b8745174fb570da57a5fe7abb6685928d4b;hb=HEAD

I've briefly looked at those patches and have a few comments.
My primary targets are lowly embedded systems, mostly ARM based.

- There seems to be no clear information about the downsides
  of the hardening patches, e.g. wrt code size and performance
  How about binary compatibility between hardened and unhardened

- Can the hardened toolchain build kernels?  E.g. ARM support
  for -fstack-protector was added in 2.6.35 c743f38013aeff58ef6252601e397b5ba281c633,
  I have no idea about other architiectures.

- Do the PIE + RELRO changes work with uClibc?

- gcc-4.4.5-fortify_source-1.patch mixes three changes
  in one patch:
    1. -D_FORTIFY_SOURCE=2 default
    2. "always overflow error"
    3. some unspcified changes in libjava/java/lang/
  I like 1., but 2. is an ugly hack (using getenv() to disable
  the error), and 3. is unclear to me

- gcc-4.4.5-fpie-1.patch mixes:
    1. -fPIE default
    2. RELRO default
    3. -Wl,--fatal-warnings
  I think 1. is good (although it defeats prelink,,
  but 2. impacts startup time due to BIND_NOW; not sure about 3.

- gcc-4.4.5-fstack_protector-1.patch looks good

I think the patches might need to be split, and there should
be a config option for each patch which spells out the upsides
and downsides in the help text so the user has all the information
to make the right choice.


For unsubscribe information see

More information about the crossgcc mailing list