Re: [RFC PATCH] dpkg-buildflags: Switch to -fstack-protector-strong
On Tue, Jun 24, 2014 at 10:11 AM, Kees Cook wrote:
> On Tue, Jun 24, 2014 at 11:29:31AM +0200, Romain Francoise wrote:
>> Hi,
>>
>> GCC 4.9 supports a new stack protector implementation, enabled via the
>> -fstack-protector-strong flag, which provides a better balance between
>> security and performance than the default implementation that we're
>> currently using. This new flag is already used by Fedora 20 and
>> ChromeOS. See the following for more information:
>
> Thanks for testing this! I would love to see this change go into the
> archive.
>
>> https://lwn.net/Articles/584225/
>> http://www.outflux.net/blog/archives/2014/01/27/fstack-protector-strong/
>> https://fedorahosted.org/fesco/ticket/1128
>>
>> The Security Team has expressed interest in switching dpkg-buildflags
>> over to this new flag in Debian for jessie, now that GCC 4.9 is the
>> default compiler on all release architectures. In order to see the
>> impact on the archive, David Suárez did a full rebuild on EC2 with a
>> patched dpkg-dev which emits the new flag.
>>
>> There are only 16 new failures, which can be categorized as follows:
>>
>> * explicitly build-depends on and uses gcc/g++ 4.8, which doesn't
>> understand -fstack-protector-strong:
>> - ccbuild 2.0.6-2.1
>> - chromium-browser 35.0.1916.153-2
>> - contextfree 3.0.5+dfsg1-2.1
>> - flexc++ 2.01.00-1
>> - gpg-remailer 3.00.02-1
>> - higan 094-4
>> - llvm-toolchain-snapshot 1:3.5~svn209039-2
>> - openimageio 1.4.9~dfsg0-1 (already fixed in -2)
>> - oxref 1.00.01-1
>> - spek 0.8.2-3.1
>> - webkitgtk 2.4.3-2
>>
>> * explicitly build-depends on and uses gcc 4.6:
>> - estic 1.61-20.1 (#747980)
>>
>> * explicitly build-depends on and uses Clang 3.4:
>> - feel++ 1:0.98.0-final-1
>
> I wonder if there is any sensible way for dpkg-buildflags to detect (or
> maybe just be told) which compile will be used for a build? Perhaps it
> could take a new argument that would allow it to select flags based on the
> compiler name and version?
>
> dpkg-buildflags --compiler=gcc-4.7
There are very legitimate reasons for using an older gcc version, and
breaking all the packages that do that is sort of unkind.
Especially when some of them already export either CC=gcc-4.8 or
CXX=g++-4.8 in debian/rules (like chromium, oxref, and spek), which
would make it rather convenient to detect the compiler in use. Other
packages in that set don't do that but patches could be proposed for
those packages so they don't have this problem in the future.
So, I think before any upload with this change, dpkg-buildflags needs
to be able to process those flags if they're set and fall back to
emitting the older build flags when it gets gcc < 4.9.
Plus, there will be future situations like this, and if this is
already implemented, a bunch of similar problems will be avoided. So
in general, it's just good hygiene.
Best wishes,
Mike
P.S. This affects me with chromium, which has crashing bugs on gcc
4.9, which is why 4.8 is currently hardcoded. Those problems will be
fixed in 37, but that isn't going to be released for a couple months.
Reply to: