[ubuntu-hardened] [16.04 LTS] Why Linux kernel is compiled using "-fstack-protector-all" option, instead of previously used "strong" variant?
sbeattie at ubuntu.com
Fri Sep 22 18:16:28 UTC 2017
On Sun, Sep 17, 2017 at 12:32:13PM +0200, daniel curtis wrote:
> For some time, I'm noticing, that the kernel in 16.04 LTS Release is
> compiled with a runtime stack overflow checking, using
> "-fstack-protector-all" option instead of, used earlier,
> "-fstack-protector-strong". What is the reason for such a change? Something
> As we know, "-fstack-protector-all" option will protect all functions,
> right? But "-fstack-protection-strong" has been developed to broaden the
> scope of the stack protection. (As an additional plus, "any function using
> local register variables will be protected" also.) Maybe the reason is: the
> ultra-paranoid "all" considered as a better solution?
> I'm asking about this, because a couple of weeks ago, new Linux kernels
> were build with "-fstack-protector-strong" option. Now, there is
> "-fstack-protector-all" in use. It seems, that adding
> "-fstack-protector-all" to all compile commands, can brings big performance
> penalty. And most important thing: "-fstack-protector-strong", that hits
> the balance between "-fstack-protector" and "-fstack-protector-all", right?
> So, are there any plans to compile/build Linux kernel for 16.04 LTS Release
> using "-fstack-protector-strong" just as before? Here are two latest build
> logs for v4.4.0-95 and v4.4.0-96 (I've checked these changes for i386 and
> amd64 architectures.)
> In both cases, "-fstack-protector-all" were used. What is the reason for
> such a change? "-fstack-protector-strong" seems to be a better solution
> form a security point of view, right? So, why such a sudden change? Are
> there any plans to return to the "strong" variant?
> Sorry, if I made a mistake with my question. But, I was really surprised
> that the "all" option is in use. (Earlier, Linux kernels for the 16.04 LTS
> was compiled with "strong" variant.)
This is actually an interesting question.
First, whether the compiler's -fstack-protector option is enabled and
which version is used when building the kernel is (supposed to be)
set by the CONFIG_CC_STACKPROTECTOR set of kernel config options, and
in Ubuntu 16.04 LTS, the intent is to have -fstack-protector-strong
for the kernel. And indeed, if we look at the config for the 4.4.0-96
kernel, it's set for -fstack-protector-strong:
$ grep STACKPROTECTOR /boot/config-4.4.0-96-generic
# CONFIG_CC_STACKPROTECTOR_NONE is not set
# CONFIG_CC_STACKPROTECTOR_REGULAR is not set
So, why are we seeing -fstack-protector-all show up in newer kernel
Kernel build logs are a bit confusing, because by default (unless
V=1 is set as a variable), the kernel builds elide the compilation
invocation. However, for some reason, in the logs above, the build
has emitted them for the tools/perf/ subdirectory, which is where you
see the -fstack-protector-all as part of the compilation invocation.
Note that the perf tools are user space tools, providing the
user-space portion of the perf subsystem. They are included as part
of the linux-tools-4.4.0-ABI-generic package (it's best to install
the linux-tools-generic metapackage). They are not part of the kernel
proper or its modules.
Looking at tools/perf/config/Makefile in the kernel source
we can see that the perf tools will be built with -fstack-protector-all
if the compiler used supports the option. But, that Makefile hasn't been
touched since 2015:
Thus, the user space perf tools have been built with
-fstack-protector-all for quite a while. Indeed, the ttols/perf build
has attempted to use it since 2009(!):
So why has it started showing up in the buildlog recently? Since the
option has been there forever, what's new is the compilation arguments
showing up. So something must be setting V=1 for at least part of the
It turns out the change you're seeing appeared between the 4.4.0-94.117
and 4.4.0-95.118 kernel builds:
Looking at the changes between 4.4.0-94.117 and 4.4.0-95.118 doesn't
show us anything obvious:
(or git log Ubuntu-4.4.0-94.117..Ubuntu-4.4.0-95.118 if you've got a
clone of the xenial kernel git tree.)
If we diff the buildlogs, we see where it crops up:
@@ -7711,52 +7711,53 @@
-SUDO_COMMAND=/usr/sbin/chroot /<<CHROOT>> su buildd -s /bin/sh -c cd '/<<PKGBUILDDIR>>' && 'env'
Note that +V=1 at the end, the buildd environment has apparently
changed/updated to set that variable. We can see that the launchpad
build environments differed in the builds:
-Buildd toolchain package versions: launchpad-buildd_147 python-lpbuildd_147 sbuild_0.67.0-2ubuntu7 bzr-builder_0.7.3+bzr174~ppa13~ubuntu14.10.1 bzr_2.7.0-2ubuntu3 git-build-recipe_0.3.4~git201611291343.dcee459~ubuntu16.04.1 git_1:2.7.4-0ubuntu1.2 dpkg-dev_1.18.4ubuntu1.2 python-debian_0.1.27ubuntu2 qemu-user-static_1:2.5+dfsg-5ubuntu10.14.
+Buildd toolchain package versions: launchpad-buildd_150 python-lpbuildd_150 sbuild_0.67.0-2ubuntu7.1 bzr-builder_0.7.3+bzr174~ppa13~ubuntu14.10.1 bzr_2.7.0-2ubuntu3.1 git-build-recipe_0.3.4~git201611291343.dcee459~ubuntu16.04.1 git_1:2.7.4-0ubuntu1.2 dpkg-dev_1.18.4ubuntu1.2 python-debian_0.1.27ubuntu2.
I'm not quite sure why it's not affecting the entire kernel build,
but that appears to be the source of the new -fstack-protector-all
messages in the build log.
I hope this clarifies things. Thanks!
<sbeattie at ubuntu.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: not available
More information about the ubuntu-hardened