On Sun, Apr 01, 2012 at 05:24:00PM +0800, Paul Wise wrote: > On Sun, Apr 1, 2012 at 3:49 PM, Kees Cook wrote: > > I'm going to work on getting this graphed daily, like the debhelper > > statistics[3]. > > If you do, please add that to the statistics wiki page: > > http://wiki.debian.org/Statistics
Ah-ha, yes. I will do that. :) > Under what circumstances do you think GCC upstream should be enabling > these options by default (as several distributions other than Debian > do)? I haven't attempted to push these things to upstream yet, but I still think it would be a great idea. Magnus Granberg from Gentoo maintains a patch against gcc for Gentoo, and has made attempts to upstream it, but I'm not sure where it stands: http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-gccpatchset.git;a=tree;f=gcc-4.7.0/piepatch;hb=HEAD > Do you have any stats about where packages had to avoid enabling these > options? I have tried to encourage Ubuntu developers to keep track of stuff that couldn't be trivially fixed here: https://wiki.ubuntu.com/ToolChain/CompilerFlags#Problems For everything else, I've tried to get patches either to the upstream directly, or to Debian. The vast majority of those have been taken. It was, honestly, a pretty short list since Gentoo did a ton of this upstreaming of fixes when they started their hardening initiative. (RedHat did a lot of work on hardening fixes too, but didn't tend to be very effective at getting them upstreamed.) I'm not sure how up to date that list, is though. I strongly suspect there are things missing from it. :) But it's really just a handful of more difficult problems vs the tens of thousands of packages in the archive. Frankly, probably the most disruptive change was -Werror=format-security, which wasn't enabled in Ubuntu (since fighting all the errors at once seemed extremely daunting). Instead, I turned it on in hardening-wrapper, and then via dpkg-buildflags to slowly ease it into the archive. > Do you feel the frequency of that is low enough to enable these > options by default (in upstream or in distros)? Take my opinion with a grain of salt, as even I recognize that I'm a bit of an extremist about this, but yes, absolutely. I succeeded in making this happen in Ubuntu, and while the path is very different in Debian, for package builds it is effectively "by default" now too (assuming the package's build system is modern and the flags are passed into the build correctly). As for the upstream compiler, I recognize they have more users than just distro builders, but it seems to me that it is irresponsible to not enable these features by default in the compiler. :) Note that the default flags in both Ubuntu and Debian lack PIE (where as Gentoo's hardening patchset includes PIE by default). The Debian hardening documentation has encouraged maintainers to enable PIE too if they have a sensitive package (daemons, media processors, browsers, interpreters, etc), so it's not totally absent. I'd like to see the default on architectures with enough general registers (e.g. amd64) include PIE. The other archs, like i386, suffer quite a bit (15% performance hit) in some cases, so while I think it should still be the default there, it's not a decision I'm likely to be able to convince more performance-sensitive people about. I'd like to push for it on amd64 once more packages are building with the default flags. We'd need the entire base system converted, though, to deal with some of the build ordering problems with switching to PIE. The problem is with shipped .a files: those object files must all be built with -fPIE for them to link into a -pie binary. (i.e. all static users of the .a need to be rebuilt after the .a is built.) It's doable, it just needs to be done careful attention given to dependency ordering. I don't think a specific flag-day would be needed. > If you think that enabling them by default in GCC upstream is doable, > what kind of blockers and timeframe would we expect for that? I think the blockers are mostly political. There are no serious technical blockers that I see (e.g. it _is_ enabled in the Ubuntu compiler). Getting it into a form that upstream gcc would be happy about is the trick. I have no sense of timeframe; I've not worked with the gcc upstream before. > I would personally like binaries not built by debian/rules but built > on Debian systems to be hardened by default. Yup. I couldn't agree more, but that decision isn't mine and has already been made. -Kees -- Kees Cook @debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120401182941.gm8...@outflux.net