adding support for hardened toolchain
Thu Jan 6 15:55:00 GMT 2011
Quoting Johannes Stezenbach <firstname.lastname@example.org>:
> 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.
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
I'm not sure if there is much out there on these topics.
> How about binary compatibility between hardened and unhardened
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
> 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,
> 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.
This message was sent using IMP, the Internet Messaging Program.
For unsubscribe information see http://sourceware.org/lists.html#faq
More information about the crossgcc