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
Reply to: