Re: Bug#552688: Please decide how Debian should enable hardening build flags
Hi Matthias,
On Thu, Jul 28, 2011 at 06:55:11PM +0200, Matthias Klose wrote:
> On 07/27/2011 11:56 PM, Raphael Hertzog wrote:
> >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'?
Do you mean via DEB_BUILD_OPTIONS? That can't really be set _in_ a
package, so we'd need something else, IIUC.
> >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.
I recall it being no more than 15% in the worst case, but yes, that was
for the register-starved architectures. I totally agree: it should not be
the default for i386. I would like to see more benchmarks for armel and
amd64, though.
The only part of PIE, I think, should be that it should be able to be
enabled trivially, so that the hardening-wrapper/includes transition is
easy for maintainers.
> >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.
Libraries are already PIC. PIE will only make a difference for the main
binary. But, as you say, worst-case situations tend to be things that use
very few library calls, like interpreters, compilers, etc. I would agree that
cc1 doesn't need to be PIE. I would, however, argue that interpreters
should be PIE, since they are frequently dealing with external input
(just think of all the utf-8 vulnerabilities that have happened over
the last few years).
But, as you mention, this is out of scope really. Let's get the rest in
place and work to make the transition not accidentally trigger feature
loss for maintainers.
-Kees
--
Kees Cook @debian.org
Reply to: