FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian GCC

 
 
LinkBack Thread Tools
 
Old 11-20-2010, 02:18 PM
Raphael Hertzog
 
Default Please decide how Debian should enable hardening build flags

reassign 552688 tech-ctte
retitle 552688 Please decide how Debian should enable hardening build flags
tag 552688 - wontfix
thanks

I think none of the discussions up to now have resulted in a consensus
among all the parties. Most people are in favor of changing the defaults
in GCC, except the gcc maintainer.

We have dpkg-buildflags available but few packages are using it and it's
unlikely they will be all converted in the wheezy timeframe. (And everytime I
discuss how packages should communicate to dpkg-buildflags whether or not
they want/support hardening build flags (and which one in particular), the
discussion stalls).

I would really like Debian to build hardened binaries by default and it
would be great if the switch could happen early in the wheezy cycle. For
this I think we need to have a clear plan and I hope the technical
committee can bring some clarity here. Either by overruling the GCC
maintainer or by designing the missing pieces so that we can at least go
forward (I would implement what's needed in dpkg-dev if I knew what's
needed).

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20101120151829.GB4506@rivendell.home.ouaza.com">ht tp://lists.debian.org/20101120151829.GB4506@rivendell.home.ouaza.com
 
Old 11-21-2010, 02:03 AM
Don Armstrong
 
Default Please decide how Debian should enable hardening build flags

On Sat, 20 Nov 2010, Raphael Hertzog wrote:
> I think none of the discussions up to now have resulted in a
> consensus among all the parties. Most people are in favor of
> changing the defaults in GCC, except the gcc maintainer.

There are a couple of things here that should be worked out first
before the CTTE can make a decision:

1) Has gcc's upstream been approached about including this patch? What
was their response?

2) Has the archive been successfully rebuilt with the proposed patch?

3) Since Matthias has indicated that he doesn't have the resources to
steward this patch in Debian, who is going to work on maintaining it
if upstream isn't interested in the patch and the CTTE decides to
override Matthias?

Alternatives to patching gcc include making dpkg-buildflags more
prevalent, a wrapper that we require to install on buildds (coupled
with throwing away binary builds), or some combination of the above.


Don Armstrong

--
I really wanted to talk to her.
I just couldn't find an algorithm that fit.
-- Peter Watts _Blindsight_ p294

http://www.donarmstrong.com http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20101121030333.GZ16131@teltox.donarmstrong.com">ht tp://lists.debian.org/20101121030333.GZ16131@teltox.donarmstrong.com
 
Old 11-21-2010, 06:39 AM
Raphael Hertzog
 
Default Please decide how Debian should enable hardening build flags

CCing Kees Cook, he has been the one leading the efforts up to now. I hope
he can answer your queries.

Hi,

On Sat, 20 Nov 2010, Don Armstrong wrote:
> There are a couple of things here that should be worked out first
> before the CTTE can make a decision:
>
> 1) Has gcc's upstream been approached about including this patch? What
> was their response?

No idea.

> 2) Has the archive been successfully rebuilt with the proposed patch?

I think this patch is used in Ubuntu, so mostly yes. I guess Kees Cook or
Steve Langasek should be able to tell us a bit more.

> 3) Since Matthias has indicated that he doesn't have the resources to
> steward this patch in Debian, who is going to work on maintaining it
> if upstream isn't interested in the patch and the CTTE decides to
> override Matthias?

Kees, would you be willing to take this responsibility in that case?

> Alternatives to patching gcc include making dpkg-buildflags more
> prevalent, a wrapper that we require to install on buildds (coupled
> with throwing away binary builds), or some combination of the above.

Indeed.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20101121073921.GB11156@rivendell.home.ouaza.com">h ttp://lists.debian.org/20101121073921.GB11156@rivendell.home.ouaza.com
 
Old 11-21-2010, 07:21 AM
Matthias Klose
 
Default Please decide how Debian should enable hardening build flags

On 21.11.2010 08:39, Raphael Hertzog wrote:

CCing Kees Cook, he has been the one leading the efforts up to now. I hope
he can answer your queries.

Hi,

On Sat, 20 Nov 2010, Don Armstrong wrote:

There are a couple of things here that should be worked out first
before the CTTE can make a decision:


I assume that there is a decision to turn on hardening defaults? Who made it,
and which defaults to turn on? Which ports should it use? Where is it
documented? So involvement of the ctte seems to be a bit premature, asking the
*how* before the *if*. As said before in the report, it should be reassigned to
`general'.



1) Has gcc's upstream been approached about including this patch? What
was their response?


No idea.


Afaik, not submitted, and not upstreamable in this form.


2) Has the archive been successfully rebuilt with the proposed patch?


I think this patch is used in Ubuntu, so mostly yes. I guess Kees Cook or
Steve Langasek should be able to tell us a bit more.


3) Since Matthias has indicated that he doesn't have the resources to
steward this patch in Debian, who is going to work on maintaining it
if upstream isn't interested in the patch and the CTTE decides to
override Matthias?


Kees, would you be willing to take this responsibility in that case?


The patch itself is "maintained", however it requires patches to the testsuite
which are not maintained. They are in 4.4, partially forwarded, incomplete for
4.5 and not done at all for trunk. So I do have an answer about the
responsibility (and no, you won't convince me otherwise in a few weeks or months
having seen this for years).


An additional effort is testing with upstream builds for submitting bug reports.
I didn't see anybody to step up with this testing, when the toolchain diverges
much more, compared to upstream.



Alternatives to patching gcc include making dpkg-buildflags more
prevalent, a wrapper that we require to install on buildds (coupled
with throwing away binary builds), or some combination of the above.


yes, I consider the current solution a hack, introduced in some derivates by the
lack of resources to get it done properly as nearly any other distribution is
doing it. Changes to the build flags should be injected in the package build
system, not by changing the compiler itself. I first submitted a patch to
introduce default flags from the environment, this was replaced/refined by
dpkg-buildflags. Now please work on getting it honored in the package builds
and maybe make it a policy for packages with a certain priority.


Matthias


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4CE8D697.2060104@debian.org">http://lists.debian.org/4CE8D697.2060104@debian.org
 
Old 11-21-2010, 07:39 AM
Raphael Hertzog
 
Default Please decide how Debian should enable hardening build flags

Hi,

On Sun, 21 Nov 2010, Matthias Klose wrote:
> I assume that there is a decision to turn on hardening defaults?
> Who made it, and which defaults to turn on? Which ports should it
> use? Where is it documented? So involvement of the ctte seems to
> be a bit premature, asking the *how* before the *if*. As said
> before in the report, it should be reassigned to `general'.

Any past discussion that I remember, a vast majority of people were in
favor of hardening and discussions stalled on the implementation details.
I don't think that reassigning it to general will help in any way.

> An additional effort is testing with upstream builds for submitting
> bug reports. I didn't see anybody to step up with this testing,
> when the toolchain diverges much more, compared to upstream.

I don't understand what you are referring to here. Can you elaborate a
bit?

> yes, I consider the current solution a hack, introduced in some
> derivates by the lack of resources to get it done properly as nearly
> any other distribution is doing it. Changes to the build flags
> should be injected in the package build system, not by changing the
> compiler itself. I first submitted a patch to introduce default
> flags from the environment, this was replaced/refined by
> dpkg-buildflags. Now please work on getting it honored in the
> package builds and maybe make it a policy for packages with a
> certain priority.

I think the proper solution is a combination of both approaches. There's
no reason we should continue to not have hardened builds for all packages
right now (in particular when everybody else have them).

Packages should be able to opt-in/opt-out by using dpkg-buildflags
properly. The flags returned by dpkg-buildflags could include some sort of
"--no-magical-defaults-behind-my-back" so that dpkg-buildflags is then
entirely in control, and it can even disable hardening build for the
packages where it breaks.

The day when all packages are using dpkg-buildflags properly, then we can
drop that patch in gcc.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20101121083941.GE11156@rivendell.home.ouaza.com">h ttp://lists.debian.org/20101121083941.GE11156@rivendell.home.ouaza.com
 
Old 01-21-2011, 06:55 PM
Kees Cook
 
Default Please decide how Debian should enable hardening build flags

On Sat, Nov 20, 2010 at 04:18:29PM +0100, Raphael Hertzog wrote:
> We have dpkg-buildflags available but few packages are using it and it's
> unlikely they will be all converted in the wheezy timeframe. (And everytime I
> discuss how packages should communicate to dpkg-buildflags whether or not
> they want/support hardening build flags (and which one in particular), the
> discussion stalls).

It would be easy to add hardening-includes a dep of dpkg-buildflags, and
have it pull in the defaults. (Though perhaps PIE should be turned off by
default in this case.)

> I would really like Debian to build hardened binaries by default and it
> would be great if the switch could happen early in the wheezy cycle. For
> this I think we need to have a clear plan and I hope the technical
> committee can bring some clarity here. Either by overruling the GCC
> maintainer or by designing the missing pieces so that we can at least go
> forward (I would implement what's needed in dpkg-dev if I knew what's
> needed).

I stand by my preference for this being done in the compiler defaults
itself. I've been maintaining in Ubuntu for years now, it's not very hard
to keep the patch up to date.

That said, I do recognize that it creates a delta from upstream gcc and
makes it harder to diagnose compiler bugs. I would like to have upstream
take a --configure build-time option for gcc for these defaults, but I
haven't made any headway on it.

--
Kees Cook @debian.org


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110121195506.GH4979@outflux.net">http://lists.debian.org/20110121195506.GH4979@outflux.net
 
Old 01-21-2011, 07:00 PM
Kees Cook
 
Default Please decide how Debian should enable hardening build flags

Hi Raphael,

On Sun, Nov 21, 2010 at 08:39:21AM +0100, Raphael Hertzog wrote:
> On Sat, 20 Nov 2010, Don Armstrong wrote:
> > There are a couple of things here that should be worked out first
> > before the CTTE can make a decision:
> >
> > 1) Has gcc's upstream been approached about including this patch? What
> > was their response?
>
> No idea.

Zorry from Gentoo was working on a --configure option. In general, upstream
gcc is against global behavioral changes like this. I can try to open some
discussion with them, though.

> > 2) Has the archive been successfully rebuilt with the proposed patch?
>
> I think this patch is used in Ubuntu, so mostly yes. I guess Kees Cook or
> Steve Langasek should be able to tell us a bit more.

Yes, all of Ubuntu has been compiled with hardening enabled since Oct 2008.
As mentioned in the original thread[1], the only thing needed to turn it on
in Debian is to just not filter the patch list in Debian[2].

[1] http://lists.debian.org/debian-gcc/2009/10/msg00186.html
[2] http://outflux.net/hardening-for-all.patch

> > 3) Since Matthias has indicated that he doesn't have the resources to
> > steward this patch in Debian, who is going to work on maintaining it
> > if upstream isn't interested in the patch and the CTTE decides to
> > override Matthias?
>
> Kees, would you be willing to take this responsibility in that case?

I already am maintaining this patchset (since it is used in Ubuntu, and the
package is shared between Debian and Ubuntu). The core of Matthias's
objection to using it in Debian is that it it leaves him with no "stock"
gcc to diagnose compiler bugs with. While "gcc-snapshot" exists, there is
nothing like "gcc-4.5-stock", though perhaps that might be a solution to
that objection, though that would add yet-another-package-of-gcc.

-Kees

--
Kees Cook @debian.org


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110121200026.GI4979@outflux.net">http://lists.debian.org/20110121200026.GI4979@outflux.net
 
Old 01-21-2011, 07:07 PM
Kees Cook
 
Default Please decide how Debian should enable hardening build flags

Hi Matthias,

On Sun, Nov 21, 2010 at 09:21:43AM +0100, Matthias Klose wrote:
> I assume that there is a decision to turn on hardening defaults?
> Who made it, and which defaults to turn on? Which ports should it
> use? Where is it documented? So involvement of the ctte seems to

The hardening-wrapper package has all of the combinations and ports
well-declared. For example:

ifneq (,$(filter $(DEB_HOST_ARCH_CPU), ia64 alpha mips mipsel hppa arm ))
# Stack protector disabled on ia64, alpha, mips, mipsel, hppa.
# "warning: -fstack-protector not supported for this target"
# Stack protector disabled on arm (ok on armel).
# compiler supports it incorrectly (leads to SEGV)
DEB_BUILD_HARDENING_STACKPROTECTOR ?= 0
endif
DEB_BUILD_HARDENING_STACKPROTECTOR ?= 1

etc

> The patch itself is "maintained", however it requires patches to the
> testsuite which are not maintained. They are in 4.4, partially
> forwarded, incomplete for 4.5 and not done at all for trunk. So I
> do have an answer about the responsibility (and no, you won't
> convince me otherwise in a few weeks or months having seen this for
> years).

Since this, I've gotten half the testsuite changes into upstream, so this
has improved. The testsuite work is extremely time-consuming, and I've been
very slow to get that work done, unfortunately.

> yes, I consider the current solution a hack, introduced in some
> derivates by the lack of resources to get it done properly as nearly
> any other distribution is doing it. Changes to the build flags
> should be injected in the package build system, not by changing the
> compiler itself. I first submitted a patch to introduce default
> flags from the environment, this was replaced/refined by
> dpkg-buildflags. Now please work on getting it honored in the
> package builds and maybe make it a policy for packages with a
> certain priority.

This is likely the core of the disagreement: how to apply the
flags. I have a strong opinion about this because my perspective is
security-oriented. I think all compiles should be hardened; default
to being secure, and whitelist that which needs things disabled. Same
policy applies to firewalls, etc. As before, I stand by my original email
that started this thread:
http://lists.debian.org/debian-gcc/2009/10/msg00186.html

-Kees

--
Kees Cook @debian.org
 
Old 07-26-2011, 09:32 PM
Raphael Hertzog
 
Default Please decide how Debian should enable hardening build flags

Hi,

On Sat, 20 Nov 2010, Raphael Hertzog wrote:
> I would really like Debian to build hardened binaries by default and it
> would be great if the switch could happen early in the wheezy cycle. For
> this I think we need to have a clear plan and I hope the technical
> committee can bring some clarity here. Either by overruling the GCC
> maintainer or by designing the missing pieces so that we can at least go
> forward (I would implement what's needed in dpkg-dev if I knew what's
> needed).

So we just had some discussion with Steve Langasek, Ian Jackson, Bdale
Garbee, me and Matthias Klose on this topic. I'll try to summarize the
outcome here. It's probably a good idea to be familiar with the
current dpkg-buildflags features before reading this mail, so check
"man dpkg-buildflags" if needed.

The consensus seems to be that we do not want to take the "gcc patch"
approach and thus we're not going to overrule the maintainer. The bulk
of the discussion then drifted on deciding how (hardening) build flags
should be injected in the package build process.

We evaluated how dpkg-buildflags can be used for this. For most
autoconf/automake-based build systems there are 2 ways to inject flags:
1/ On the ./configure command line:
./configure --with-foo CFLAGS="..." LDFLAGS="..." ...
2/ In the environment

The first form seem to be preferred but both approaches work and should be
properly supported. However dpkg-buildflags does not easily support the
former approach. This is something that should be fixed.

TODO: implement "dpkg-buildflags --export=configure" that outputs
“CFLAGS="…" LDFLAGS="…" ...” so that a maintainer can do
./configure --with-foo $(shell dpkg-buildflags --export=configure)

Also up to now, dpkg-buildflags has only been designed to return the
default build flags and it was my expectation that maintainers would
tweak its output should this be necessary (either to add flags or to
drop them, etc.).

Unfortunately recent experience proved that dpkg-buildflags is likely to
be called by various helpers and thus not in direct control of the
maintainer via the rules files (unless all the helper provide their own
way to do this but we really would like to avoid having severals ways
to do the same thing). The current git version of dpkg already has support
for debian/buildflags{,.<arch>} to allow maintainers to post-process
the resulting buildflags but while this interface works for 95% of the
easy cases, it can't cover them all because we have stuff like packages
doing several builds of the same code with different build options (for
example -Os for udebs) or adding flags depending on which compiler is
actually in use. So the correct interface to feed post-processing
instructions to dpkg-buildflags is environment variables (because this way
we can call dpkg-builflags multiple times with different values to the
environment variable as part of the debian/rules logic).

TODO: revert debian/buildflags support, and implement
support for the environment variable DEB_<flag>_MAINT_<operation> which
work exactly like the corresponding DEB_<flag>_<operation> except it's
meant to be used by the package maintainer within debian/rules.

Another limitation of dpkg-buildflags thas has been brought up is that
it only allows to append build flags and not to drop them. While it's
often possible to disable some option by providing the opposite option
later on the command line (e.g. "... --foo ... --no-foo"), it has been
pointed out that the possibility to drop them is useful in particular when
you would like to use another compiler that doesn't understand the
option in question. Also it's cleaner as the resulting command line is
shorter and more readable.

TODO: add a "STRIP" operation to the set of operations supported by
dpkg-buildflags. DEB_CFLAGS_MAINT_STRIP="--foo --bar" would basically
drop all occurrences of --foo and --bar in the returned build flags.

QUESTION: Is this ok to assume that all build flags can be "delimited"
by a space character?

Assuming that all those improvements are done, the consensus was that
it's fine for dpkg-buildflags to start emitting the hardening build
flags by default. According to Ubuntu's experience only a few dozen of
packages are broken by the presence of these flags and those packages
should just be updated to use the new STRIP operation to drop the
problematic flags. This could be dealt as part of a wheezy release goal.

Obviously those new flags will only be picked by packages already using
dpkg-buildflags but that already includes packages using "dh" since it uses
dpkg-buildflags to set the corresponding environment variable and
also packages using CDBS (AFAIK). The other remaining packages would have
to be updated by hand (and could also be part of a release goal).

The discussion mainly covered automake/autoconf-based build systems and
obviously there are some packages using alternate build systems where
this out-of-the-box support by dh/CDBS will not be enough. In those cases,
it's still up to the maintainer to adapt whatever is needed to feed
the build flags in the appropriate way.

Hopefully I have not forgotten anything important and I have correctly
summarized the whole discussion (which was rather dense for a 1h
discussion).

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
 
Old 07-29-2011, 07:56 AM
Steve Langasek
 
Default Please decide how Debian should enable hardening build flags

On Tue, Jul 26, 2011 at 11:32:27PM +0200, Raphael Hertzog wrote:
> TODO: add a "STRIP" operation to the set of operations supported by
> dpkg-buildflags. DEB_CFLAGS_MAINT_STRIP="--foo --bar" would basically
> drop all occurrences of --foo and --bar in the returned build flags.

> QUESTION: Is this ok to assume that all build flags can be "delimited"
> by a space character?

Counterexample: -Wl,-z -Wl,defs

While this *can* also be written as -Wl,-z,defs, I'm not sure there's any
way to guarantee it will be?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110729075634.GH10101@virgil.dodds.net">http://lists.debian.org/20110729075634.GH10101@virgil.dodds.net
 

Thread Tools




All times are GMT. The time now is 08:07 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org