adding support for hardened toolchain

Heiko Zuerker
Thu Dec 30 14:20:00 GMT 2010

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...


   Heiko Zuerker

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

For unsubscribe information see

More information about the crossgcc mailing list