This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: adding support for hardened toolchain


Quoting Bryan Hundven <bryanhundven@gmail.com>:

On Thu, Dec 30, 2010 at 4:43 AM, Heiko Zuerker <heiko@zuerker.org> wrote:
Quoting Bryan Hundven <bryanhundven@gmail.com>:

On Wed, Dec 29, 2010 at 7:20 PM, Arnaud Lacombe <lacombar@gmail.com>
wrote:

Hi,


On Wed, Dec 29, 2010 at 2:15 PM, Heiko Zuerker <heiko@zuerker.org> 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:

http://www.gentoo.org/proj/en/hardened/hardened-toolchain.xml

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

--

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]