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:45 PM
Jonathan Nieder
 
Default Bug#552688: Please decide how Debian should enable hardening build flags

Hi,

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.

I agree with the precise meaning of this statement, but the spirit seems
quite wrong. For the packages I am involved in (not many), I have
deliberately not used dpkg-buildflags to make backporting easier.
It is a new facility but a very good one, and I suspect that it will
be adopted fairly quickly, especially if someone writes the appropriate
patches to debian/rules (or even better, writes a program maintainers
can use to automate this).

Also, I am not the GCC maintainer, but from experience of receiving
reports from people building software with Ubuntu, I think changing
the defaults in GCC is quite wrong.

Just my two cents.
Jonathan


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20101120154537.GA10092@burratino">http://lists.debian.org/20101120154537.GA10092@burratino
 
Old 11-20-2010, 02:50 PM
dave b
 
Default Bug#552688: Please decide how Debian should enable hardening build flags

On 21 November 2010 02:45, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi,
>
> 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.
>
> I agree with the precise meaning of this statement, but the spirit seems
> quite wrong. *For the packages I am involved in (not many), I have
> deliberately not used dpkg-buildflags to make backporting easier.
> It is a new facility but a very good one, and I suspect that it will
> be adopted fairly quickly, especially if someone writes the appropriate
> patches to debian/rules (or even better, writes a program maintainers
> can use to automate this).
>
> Also, I am not the GCC maintainer, but from experience of receiving
> reports from people building software with Ubuntu, I think changing
> the defaults in GCC is quite wrong.

Why do you think this?


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTi=9P9Sz2RkYbmvkQUo7NFNuE=NpieXcEKgRJ4QT@mail .gmail.com">http://lists.debian.org/AANLkTi=9P9Sz2RkYbmvkQUo7NFNuE=NpieXcEKgRJ4QT@mail .gmail.com
 
Old 11-20-2010, 03:09 PM
Jonathan Nieder
 
Default Bug#552688: Please decide how Debian should enable hardening build flags

dave b wrote:
> On 21 November 2010 02:45, Jonathan Nieder <jrnieder@gmail.com> wrote:

>> Also, I am not the GCC maintainer, but from experience of receiving
>> reports from people building software with Ubuntu, I think changing
>> the defaults in GCC is quite wrong.
>
> Why do you think this?

Well, I should scale that back a little and say, an easy way for
individual users to turn on hardening build flags in GCC is very
welcome.

My comment is really about the default. The main problem I had in
mind is that with -D_FORTIFY_SOURCE=2, if you are not specifically
coding with that in mind, there are spurious warnings like this:

some-file.c:70: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result

Sometimes that may be a welcome warning, but often enough one knows
very well that errors are being ignored. And

(void) whatever_function(...

does not suppress this; you instead have to uglify your code like so:

int unused = whatever_function(...

The consequences are worst when a person or project makes the
misguided choice of using -Werror on code he is not developing.
Then with a GCC update, the code starts to fail to build from source,
for confusing reasons like the above, without much of an upside to
the non-developer to offset that.

That said, the burden of handling fallout like this seems perfectly
acceptable for a project like Debian to take on. It is not such a
cost for secure code. That is why I would be happy to see hardening
flags added for the build of Debian packages, though not for the
default invocation of gcc.

Hoping that is clearer.
Jonathan


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20101120160931.GA10129@burratino">http://lists.debian.org/20101120160931.GA10129@burratino
 
Old 11-21-2010, 07:45 PM
Don Armstrong
 
Default Bug#552688: Please decide how Debian should enable hardening build flags

On Sun, 21 Nov 2010, Matthias Klose 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:
>
> I assume that there is a decision to turn on hardening defaults?

No one has decided anything. I'm asking questions to figure out if the
CTTE should decide something, or whether it needs to send the problem
back for detailed design work, or if there is a known blocker that we
just don't have available manpower to resolve.

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

Your answer is that you don't want the responsibility of dealing with
the test suite changes; that's fine. This means that if we are going
to decide to include the hardening patch, someone needs to be stepping
up to fix the test suite and forward the patches. [Why is this not a
problem for Ubuntu, BTW?]


Don Armstrong

--
To steal ideas from one person is plagiarism; to steal from many is
research.
-- Steven Wright

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: 20101121204502.GA16131@teltox.donarmstrong.com">ht tp://lists.debian.org/20101121204502.GA16131@teltox.donarmstrong.com
 
Old 01-24-2011, 08:26 PM
Don Armstrong
 
Default Bug#552688: Please decide how Debian should enable hardening build flags

On Fri, 21 Jan 2011, Kees Cook wrote:
> 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

1) Can a complete patch to enable hardening by default include
specific documentation on how to disable it? [Can this "return to a
default compiler" be made simpler than switching the three or four
options currently used?]

2) The current state of the patch doesn't properly document that the
flag is on by default; if the patch is enabled, it should say so in
the documentation, not referencing a version of Ubuntu.

3) Who is willing to do a complete rebuild with the patch enabled and
handle filing any bugs (with appropriate patches, ideally) that turn
up? [On how many architectures?]

4) What solution would you enact if the CTTE were to have hardening be
on by default for all Debian packages, but disabled by default for the
compiler as shipped?

Matthias: if #3 were to be done, and some mechanism of either doing #4
or #1 were required, what additional objections (if any) would you
have?


Don Armstrong

--
Let me bring you up to speed:
We know nothing.
You are now up to speed.
-- Steve Martin as Inspector Clouseau in _The Pink Panther 2_ (2009)

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: 20110124212600.GN19347@rzlab.ucr.edu">http://lists.debian.org/20110124212600.GN19347@rzlab.ucr.edu
 
Old 01-24-2011, 10:05 PM
Kees Cook
 
Default Bug#552688: Please decide how Debian should enable hardening build flags

On Mon, Jan 24, 2011 at 01:26:00PM -0800, Don Armstrong wrote:
> On Fri, 21 Jan 2011, Kees Cook wrote:
> > 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
>
> 1) Can a complete patch to enable hardening by default include
> specific documentation on how to disable it? [Can this "return to a
> default compiler" be made simpler than switching the three or four
> options currently used?]

Anything is possible, but nothing like this exists at the moment. While it
might be possible to invent some kind of --no-hardening option that would
disable the defaults, it would take a non-trivial amount of time to
implement, especially since the defaults must currently be implemented in 3
separate ways (spec updates, warning state defaults, and built-in defines).
If this fell to me, I would probably want to fold this into getting the
upstream configure option accepted, but that's still down on my priority
list.

There are effectively 4 sets of options in the compiler hardening patches:

-Wformat -Wformat-security
-D_FORTIFY_SOURCE=2
-fstack-protector --param ssp-buffer-size=4
-Wl,-z,relro

I should mention: PIE (-pie -fPIE) is _not_ included in the compiler
defaults patch. This is only done via the hardening-wrapper
package. Building PIE by default in the compiler is something I haven't
finished testing. (Also note that included with PIE is -Wl,-z,now since
it's not hugely useful as a defensive ELF feature without PIE. Though since
it seems that with the symbol hash table now, there isn't a penalty in
using it so maybe it should become a stand-alone default. Needs more
research...)

> 2) The current state of the patch doesn't properly document that the
> flag is on by default; if the patch is enabled, it should say so in
> the documentation, not referencing a version of Ubuntu.

Sure, this could easily be changed. It does say things are on by default,
but the "since when" language would need to be changed to reflect the
inclusion of Debian.

> 3) Who is willing to do a complete rebuild with the patch enabled and
> handle filing any bugs (with appropriate patches, ideally) that turn
> up? [On how many architectures?]

Is there infrastructure to do a full archive rebuild on all architectures?
I've always filed bugs (usually with patches) in Debian for any issues I've
noticed in Ubuntu from building with the hardening options enabled, so at
least i386, amd64, powerpc, sparc, and armel should be relatively free from
complications. I do not know what to expect from hppa and m68k, but at
least hardening-wrapper has build-time tests and logic to avoid broken
situations -- this logic may need to be moved into the gcc package if the
defaults are enabled there (since Ubuntu builds only a subset of the Debian
archs).

> 4) What solution would you enact if the CTTE were to have hardening be
> on by default for all Debian packages, but disabled by default for the
> compiler as shipped?

One of the options would be to use hardening-wrapper with a config file
on the buildds. The wrapper already reads /etc/hardening-wrapper.conf,
so that DEB_BUILD_HARDENING=1 can be set globally. If the wrapper were
part of build-essential or pre-installed in the buildd chroots and the
buildds had this turned on (probably with DEB_BUILD_HARDENING_PIE=0
for archs that had low general register counts like ia32), the entire
archive would be built with hardening without any changes to the compiler.

I suspect some people will utterly hate this idea, though, but it will
work. Though the global defaults can even be explicitly disabled in a
build (debian/rules exporting DEB_BUILD_HARDENING=0, or some subset,
for example) if there were packages with specific issues.

-Kees

--
Kees Cook @debian.org
 
Old 01-25-2011, 09:29 AM
Vincent Danjean
 
Default Bug#552688: Please decide how Debian should enable hardening build flags

Hi,

On 25/01/2011 00:05, Kees Cook wrote:
> On Mon, Jan 24, 2011 at 01:26:00PM -0800, Don Armstrong wrote:
>> 4) What solution would you enact if the CTTE were to have hardening be
>> on by default for all Debian packages, but disabled by default for the
>> compiler as shipped?
>
> One of the options would be to use hardening-wrapper with a config file
> on the buildds. The wrapper already reads /etc/hardening-wrapper.conf,
> so that DEB_BUILD_HARDENING=1 can be set globally. If the wrapper were
> part of build-essential or pre-installed in the buildd chroots and the
> buildds had this turned on (probably with DEB_BUILD_HARDENING_PIE=0
> for archs that had low general register counts like ia32), the entire
> archive would be built with hardening without any changes to the compiler.
>
> I suspect some people will utterly hate this idea, though, but it will
> work. Though the global defaults can even be explicitly disabled in a
> build (debian/rules exporting DEB_BUILD_HARDENING=0, or some subset,
> for example) if there were packages with specific issues.

As a teacher, I (most exactly my students) found find extremely annoying
that re-running a program does not lead to the exact same execution (and
in-memory layout so that memory corruption are more easily found when the
program is restarted under gdb).
So, it seems to me important that it is, at least, easy to disable
hardening (at least the parts that introduce some randomness) by default
in the compiler when the admin (or the user) wants it.

Regards,
Vincent

> -Kees
--
Vincent Danjean GPG key ID 0x9D025E87 vdanjean@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87
Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://people.debian.org/~vdanjean/debian unstable main


--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D3EA607.2050003@free.fr">http://lists.debian.org/4D3EA607.2050003@free.fr
 
Old 07-27-2011, 09:56 PM
Raphael Hertzog
 
Default Bug#552688: Please decide how Debian should enable hardening build flags

Hi,

On Tue, 26 Jul 2011, Raphael Hertzog wrote:
> 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.

I have prepared a branch that implements all this, that also includes
hardening build flags and that modify dpkg's debian/rules to actually
use dpkg-buildflags in the way we expect maintainers to use it.

See http://anonscm.debian.org/gitweb/?p=users/hertzog/dpkg.git;a=shortlog;h=refs/heads/pu/build-flags
You can grab it with "git clone git://git.debian.org/~hertzog/dpkg.git -b
pu/build-flags".

In the course of doing this I discovered that this won't have the
expected result:
---
export DEB_CFLAGS_MAINT_APPEND = -Wall
[...]
./configure $(shell dpkg-buildflags --export=configure)
---

Apparently make doesn't export the variables to the sub-shell
run in this way but only to shells run for commands in the various
targets. So instead I have to do it this way:
./configure $(shell DEB_CFLAGS_MAINT_APPEND="-Wall" dpkg-buildflags --export=configure)

One thing that is really not clear to me is how we should handle PIE.
It's not enabled by default by the gcc patch. This means that it's not
safe to enable it by default in dpkg-buildflags because we have no idea of
its impact. While all the other options have been well tested thanks to
Ubuntu, this one was not. Yet it seems that we should still aim to use it
by default at some point. How should we handle that transition?

The current implementation in my branch is that PIE is disabled by defaut
but if you set DEB_BUILD_HARDENING_PIE=1 then it will be used. This was
easily done on top of the compatibility layer with
hardening-includes/hardening-wrapper but I'm not convinced it's an
interface we want to use for this transition.

In that case, it means that we should rebuild the archive with PIE
enabled, see what breaks, report bugs and ask people to add
DEB_CFLAGS_MAINT_STRIP="-fPIE" DEB_LDFLAGS_MAINT_STRIP="-fPIE -pie"
where required. Once most packages have been fixed, we can add
PIE to the default flags. Does this sound reasonable?

Should we go further and provide centralized variables that can be used
to strip out the precise set of build flags that each hardening "feature"
adds? For reference /usr/share/hardening-includes/hardening.make does
provide such variables.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

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


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110727215639.GB9465@rivendell.home.ouaza.com">ht tp://lists.debian.org/20110727215639.GB9465@rivendell.home.ouaza.com
 
Old 07-28-2011, 04:55 PM
Matthias Klose
 
Default Bug#552688: Please decide how Debian should enable hardening build flags

On 07/27/2011 11:56 PM, Raphael Hertzog wrote:

Hi,

On Tue, 26 Jul 2011, Raphael Hertzog wrote:

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


for strip you need to know the exact options to be passed; wouldn't it be better
to have them stripped by something like `nohardening'?



In the course of doing this I discovered that this won't have the
expected result:
---
export DEB_CFLAGS_MAINT_APPEND = -Wall
[...]
./configure $(shell dpkg-buildflags --export=configure)
---

Apparently make doesn't export the variables to the sub-shell
run in this way but only to shells run for commands in the various
targets. So instead I have to do it this way:
./configure $(shell DEB_CFLAGS_MAINT_APPEND="-Wall" dpkg-buildflags --export=configure)

One thing that is really not clear to me is how we should handle PIE.
It's not enabled by default by the gcc patch. This means that it's not
safe to enable it by default in dpkg-buildflags because we have no idea of
its impact. While all the other options have been well tested thanks to
Ubuntu, this one was not.



Yet it seems that we should still aim to use it
by default at some point. How should we handle that transition?


I did see performance penalties of more than 20% on i386 and armel when enabling
PIE by default. This shouldn't be the scope of this discussion, and I still
don't see value to rebuild the whole archive using PIE.



The current implementation in my branch is that PIE is disabled by defaut
but if you set DEB_BUILD_HARDENING_PIE=1 then it will be used. This was
easily done on top of the compatibility layer with
hardening-includes/hardening-wrapper but I'm not convinced it's an
interface we want to use for this transition.

In that case, it means that we should rebuild the archive with PIE
enabled, see what breaks, report bugs and ask people to add
DEB_CFLAGS_MAINT_STRIP="-fPIE" DEB_LDFLAGS_MAINT_STRIP="-fPIE -pie"
where required. Once most packages have been fixed, we can add
PIE to the default flags. Does this sound reasonable?


No, there's no value having cc1 built with PIE, same for number crunching
libraries, doubtful for interpreters.


Matthias


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4E31946F.9000805@debian.org">http://lists.debian.org/4E31946F.9000805@debian.org
 
Old 07-28-2011, 08:34 PM
Kees Cook
 
Default Bug#552688: Please decide how Debian should enable hardening build flags

On Wed, Jul 27, 2011 at 11:56:39PM +0200, Raphael Hertzog wrote:
> One thing that is really not clear to me is how we should handle PIE.
> It's not enabled by default by the gcc patch. This means that it's not
> safe to enable it by default in dpkg-buildflags because we have no idea of
> its impact. While all the other options have been well tested thanks to
> Ubuntu, this one was not. Yet it seems that we should still aim to use it
> by default at some point. How should we handle that transition?

While I did not make it a default in Ubuntu yet, I have done archive
rebuilds with PIE enabled. It was about 2 years ago, but they were still
interesting. The majority of things compiled fine, but the logs were huge,
so I, unfortunately, deleted them a while ago.

I really want have it be the default for at least amd64. There are a
few issues that come to mind:

- speed impact in places
Some things are genuinely slower with PIE (but I don't have amd64
benchmarks -- I only measured i386 at the time). My feeling is that
speed sensitive packages (e.g. cc1 as doko points out) would then have
the option of disabling it for their specific build. The default case,
I think, is worth it, though I haven't actually ever been able to
keep all the rebuilds I did with testing to see if there were any
problems with a running system built that way.

- assembly FTBFSes
There are a few packages (usually codecs etc) that have non-relocatable
assembly in them, so PIE builds fail to handle it, or to find an available
register to use for thunking. This is, I feel, a case-by-case issue.
Ironically, these are usually the things I'd like to see built PIE more
than other things!

- non-PIC .a file relocation
Using PIE by default means that packages shipping non-PIC .a files
suddenly produce relocatable .a files. If a package that links against
them isn't building as PIE too, it will FTBFS.

> The current implementation in my branch is that PIE is disabled by defaut
> but if you set DEB_BUILD_HARDENING_PIE=1 then it will be used. This was
> easily done on top of the compatibility layer with
> hardening-includes/hardening-wrapper but I'm not convinced it's an
> interface we want to use for this transition.

If someone chose to build-dep on hardening-wrapper/hardening-includes, they
expect to have built PIE, so I think that the dpkg-buildflags default
should likely depend on that in some way.

The problem here is that h-w/i defaults to PIE-when-supported rather than
PIE-when-supported-and-desired, so having a maintainer explicitly set
DEB_BUILD_HARDENING_PIE=1 will trigger FTBFS on the architectures that
don't support it. I think we'll need some other flag instead that means
"PIE if possible" when moving from dpkg-buildflags from h-w/i.

It might be possible to reorganize hardening.make to have
_HARDENED_PIE_CFLAGS and _HARDENED_PIE_LDFLAGS only be populated on archs
that support PIE. Right now, the selection logic is part of
HARDENING_CFLAGS and HARDENING_LDFLAGS. Or they could be exposed as a
separate set?

There's a lot of ways to do this. I'm not sure what is best. What's
important to me is that maintainers that were using h-w/i don't suddenly
end up with builds that aren't PIE, since they explicitly chose to build
with PIE (unless they also explicitly chose to disable it).

> In that case, it means that we should rebuild the archive with PIE
> enabled, see what breaks, report bugs and ask people to add
> DEB_CFLAGS_MAINT_STRIP="-fPIE" DEB_LDFLAGS_MAINT_STRIP="-fPIE -pie"
> where required. Once most packages have been fixed, we can add
> PIE to the default flags. Does this sound reasonable?

Well, this can only be done once the archive is using dpkg-buildflags,
which will be a long transition, IIUC.

> Should we go further and provide centralized variables that can be used
> to strip out the precise set of build flags that each hardening "feature"
> adds? For reference /usr/share/hardening-includes/hardening.make does
> provide such variables.

It seemed like a good idea to me (which is why hardening.make has it), so
I'd support that again. Having a common way to control the flags seems like
a very good idea.

There's also the complex case of some build systems passing -fPIC to
everything, which supersedes -fPIE unfortunately. I think this is a GCC
bug, personally, but I haven't had time to hunt it down.

-Kees

--
Kees Cook @debian.org


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

Thread Tools




All times are GMT. The time now is 04:36 PM.

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