adding support for hardened toolchain

Bryan Hundven
Wed Jan 5 18:48:00 GMT 2011

Heiko, all,

On Thu, Dec 30, 2010 at 6:20 AM, Heiko Zuerker <> wrote:
> Quoting Bryan Hundven <>:
>> On Thu, Dec 30, 2010 at 4:43 AM, Heiko Zuerker <> wrote:
>>> Quoting Bryan Hundven <>:
>>>> On Wed, Dec 29, 2010 at 7:20 PM, Arnaud Lacombe <>
>>>> wrote:
>>>>> Hi,
>>>>> On Wed, Dec 29, 2010 at 2:15 PM, Heiko Zuerker <>
>>>>> wrote:
>>>>>> Hey,
>>>>>> I'm currently applying additional patches to gcc, in order to create a
>>>>>> hardened toolchain.
>>>>> I am stupid, dare to explain what the "hardened" concretely mean in
>>>>> this context ? Does it make my toolchain proof to .454 Casull bullet ?
>>>> The patches Heiko is referring to come from the gentoo hardened
>>>> project, specifically the hardened toolchain project:
>>> The patches are actually from the Hardened Linux From Scratch, but they
>>> do
>>> the same thing basically.
>>> I had some troubles with the Gentoo ones and decided to use the same ones
>>> we've been using for years. Not sure why I was so fixated on the Gentoo
>>> patches for a while....
>> Ok. That is good to know. It is hard to get documentation on hlfs, as
>> they don't have a published guide, and I always have problems building
>> their book from svn.
> The issue right now is that the HLFS folks are struggling with what the
> right way of documenting their changes is. In addition to that the main guy
> doesn't have as much time as he used to.
>> With that, my two problems with bundling the hlfs patches with
>> crosstool-ng are:
>> 1) validating that the patches are doing what they are supposed to do.
> For the most part this is pretty straight forward. For example to find out
> if all binaries are ET_DYN, you'd be using the "scanelf" tool. That's what I
> did when I added the patches.
>> 2) if the patches do not work for all architectures and all versions
>> of tools built by crosstool-ng (that require patches), then we have to
>> make a set of special cases where:
>> * if you're using x.x.x version of {gcc,glibc,binutils,etc...}, a
>> normally hidden option would appear to allow you to enable these
>> patches?
>> It just seems to me that if you want a toolchain with these patches
>> and the above scenario from problem [2] is true, the correct choice
>> would be to use the local patch option in crosstool-ng.
>> Put your local patches in version control. A separate repo for the
>> corresponding versions of crosstool-ng and buildroot. Then write a
>> very small wrapper (shell) script that 'checks out' these
>> repositories, puts configuration files in the right spots, and runs
>> crosstool-ng/buildroot to completion of your final product.
>> I do something very similar (minus the buildroot part), and I have
>> found this to be much more flexible then trying to get custom
>> toolchain patches into crosstool-ng, hence keeping crosstool-ng as
>> flexible as possible. It is also easier for me to jump to a newer
>> version of crosstool-ng without too much pain.
> You are absolutely right with your statement, but:
> 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.
> We'll see when I actually get a chance to look into writing a patch for
> this...

After looking into this a bit more, I think I get it now, and I would
like to see this get into crosstool-ng.

It seems to me that the patch directory needs to be refactored. I
would suggest something like:


Where one of the "architecture"s would be "any" and another would be
"security", besides just x86, powerpc, arm, etc...

This makes sense, because my x86 toolchain doesn't need patches that
are specific to powerpc, and if the CT_TOOLCHAIN_HARDENING is enabled,
it will apply patches from "security". Patches that would be applied
regardless of architecture would go in "any".

> --
> Regards
>  Heiko Zuerker
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
> --
> For unsubscribe information see

Let me know what you think,


For unsubscribe information see

More information about the crossgcc mailing list