[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Reply to: