Re: adding support for hardened toolchain

[Heiko Zuerker <heiko at zuerker dot org>]

Hey,

Quoting Johannes Stezenbach <js@sig21.net>:
> 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.
>
> http://devil-linux.git.sourceforge.net/git/gitweb.cgi?p=devil-linux/devil-linux;a=tree;f=target/Devil-Linux/default/patches.ct-ng/gcc/4.4.5;h=4f163b8745174fb570da57a5fe7abb6685928d4b;hb=HEAD

Please keep in mind that I'm not the original author. These patches  
are from the HLFS project and I just backported them to 4.4.5.

> 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
>   (benchmarks).

I'm not sure if there is much out there on these topics.

>   How about binary compatibility between hardened and unhardened
>   executables?

I don't see a reason why they wouldn't.

> - Can the hardened toolchain build kernels?  E.g. ARM support
>   for -fstack-protector was added in 2.6.35  
> c743f38013aeff58ef6252601e397b5ba281c633,

Yes.

>   I have no idea about other architiectures.

I and the HLFS project used them only on x86, but it seems Gentoo  
(which uses similar patches) may use it on different platforms. I have  
no doubt that this has to be tested quite a bit.

> - Do the PIE + RELRO changes work with uClibc?

Don't know, we'll have to find out.

> - 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/natClass.cc
>   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,  
> http://lwn.net/Articles/190495/),
>   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.

This is not be a bad idea, just in case there are issues with specific  
architectures. But this would complicate the proposed patching  
directory structure even further.

I don't believe that there has been a lot of work done on hardening  
embedded systems, outside of proprietary solution.
This is one of the reasons why I brought this up, instead of just  
adding these features to Devil-Linux.

I'm sure there are going to be a few issues which we have to iron out,  
but the benefits are a much more secure system.

--

Regards
  Heiko Zuerker
  http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



--
For unsubscribe information see http://sourceware.org/lists.html#faq