Re: Switch on compiler hardening defaults
Hi Matthias,
On Sun, Nov 01, 2009 at 07:53:20PM +0100, Matthias Klose wrote:
> On 25.10.2009 19:55, Kees Cook wrote:
> >I do not expect to reach consensus with all developers on this, so I'm
> >not sure who I need to convince to move it forward. (Perhaps just the
> >GCC maintainers?) Regardless, if you agree with this, please speak up.
> >I think it's very important that this change happens.
>
> Introducing hardening defaults is a project decision, but as you may
> know I don't support the current approach to enable these defaults.
Ah, sorry. I had thought you didn't support it due to resistance from the
rest of the Debian developer community (for which I was trying to clear
the way with this thread). It seems I need to convince you directly! :)
> >Arguments against:
> > - makes the compiler's behavior different than stock compiler.
> > Rebuttal: honestly, I don't care -- it seems like such a
> > huge win for safety and is easy to debug. Debian
> > already carries plenty of patches anyway -- there
> > is no such thing as the "stock compiler".
>
> Honestly I do care. While the security team may have less work, you
> dump work on the Debian GCC maintainers with a patch which is
> unmaintained upstream, and which requires the compiler to be built
So you take issue with the effects on the gcc testsuite and the compiling
of gcc itself? I'm willing (as you know) to work on these pieces. I
didn't even consider suggesting this for Debian until I'd nailed down all
the testsuite fixes in Ubuntu's gcc.
> with --disable-werror. Getting the testsuite fixed took more than
> twelve months, and the changes to cleanly build without
> --disable-werror are missing.
I wasn't aware of the --disable-werror issue, I can go look at that. Yes,
the testsuite fixes took a long time; most of that was me coming up to
speed on the gcc packaging itself. Running individual tests was no
trivial exercise. ;)
> The GCC packages don't "already carry
> plenty of patches" of this style; you'll only see patches needed for
> packaging or backports from upstream. I don't plan to have an
> exception for this patch set. Please get the testsuite fixes
> accepted upstream, plus patches to build without --disable-werror.
So that I understand what your requirements would be:
- testsuite fixes upstream
- fixes for --disable-werror upstream
You're not implying that the defaults be made upstream -- I expect that to
be entirely impossible. There is at least one person I know of at Gentoo
that took my gcc defaults patchset and is trying to implement it as a
configure option to the gcc package. So far, upstreaming that hasn't gone
anywhere that I'm aware of.
> > - makes more work for dealing with warnings.
> > Rebuttal: those warnings are there for a reason -- they can
> > be real security issues, and should be fixed.
>
> there are some functions in glibc which are questionably declared
> with the "warn about unused result" attribute (fwrite*). This seems
> to force a programming style which not everybody agrees with (having
> to check the return value after each operation instead of checking
> errno later).
The most egregious of these were patched out of eglibc in Ubuntu.
We could do the same in Debian. As for the general problem, yes, you're
correct -- there is no way to disable the "warn unused" warnings in gcc.
Perhaps upstream would be interested in gaining that ability?
> > - makes running Debian slower.
> > Rebuttal: no, nothing supports this. The bulk of _FORTIFY_SOURCE
> > is compile-time. Run-time checks, including those from
> > -fstack-protector are just not measurable. The burden of
> > evidence for anyone claiming this is on them. I'm not
> > suggesting we turn on PIE; that option can be a problem.
>
> no, the burden would be on you. You did claim the same for PIE
> without checking yourself :-/ Please don't just check ix86.
Alone, I am not able to know all the workloads people try. This was
especially true when I was originally interested in PIE, and was unable
to create a workload that caused serious problems (but for which you
were very able to demonstrate).
An expanded version of my terse trolling might be: "Other people need to
provide testcases that demonstrate the performance problem." Without
that, it's not reasonable to show that something is broken -- I can only
do the testing of workloads I can imagine and have time to implement.
> >Inflammatory observation: Debian may be the single remaining major Linux
> >distribution that does not use the stack protector and _FORTIFY_SOURCE
> >when building its packages. I find this embarrassing. Check[6] for
> >yourself.
>
> The majority of distributions does turn on these options during
> package build time, which IMO is the right thing to do. Debian
> should do the same. There's now Raphael's new framework in place
> which makes the injection of macros in dpkg-buildpackage in the
> environment obsolete.
This would certainly be better than nothing, and better than the
hardening-wrapper package, but it would require that every package in
Debian be modified to respect external environments. Also, I think
having the compiler itself be hardened is the bigger win.
Out of curiosity, where can I and others find the documentation for the
dpkg-buildpackage environment framework? We should immediately add the
hardening options to it now for the packages that it will work on.
-Kees
--
Kees Cook @debian.org
Reply to: