[ubuntu-hardened] [16.04 LTS] Why Linux kernel is compiled using "-fstack-protector-all" option, instead of previously used "strong" variant?

Fri Sep 22 18:16:28 UTC 2017

Hi daniel,

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
> happened?
> 
> 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.)
> 
> ✓
> https://launchpadlibrarian.net/336198288/buildlog_ubuntu-xenial-i386.linux_4.4.0-95.118_BUILDING.txt.gz
> 
> ✓
> https://launchpadlibrarian.net/336759520/buildlog_ubuntu-xenial-amd64.linux_4.4.0-96.119_BUILDING.txt.gz
> 
> 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_HAVE_CC_STACKPROTECTOR=y
  CONFIG_CC_STACKPROTECTOR=y
  # CONFIG_CC_STACKPROTECTOR_NONE is not set
  # CONFIG_CC_STACKPROTECTOR_REGULAR is not set
  CONFIG_CC_STACKPROTECTOR_STRONG=y

So, why are we seeing -fstack-protector-all show up in newer kernel
build logs?

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

  https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/tree/tools/perf/config/Makefile#n188

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:

  https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/log/tools/perf/config/Makefile

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(!):

  https://git.kernel.org/linus/35ba15b737e2cd1d780943189f2138519f81fd42

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
build environment.

It turns out the change you're seeing appeared between the 4.4.0-94.117
and 4.4.0-95.118 kernel builds:

  https://launchpad.net/ubuntu/+source/linux/4.4.0-94.117
  https://launchpadlibrarian.net/335040493/buildlog_ubuntu-xenial-amd64.linux_4.4.0-94.117_BUILDING.txt.gz

  https://launchpad.net/ubuntu/+source/linux/4.4.0-95.118
  https://launchpadlibrarian.net/336198288/buildlog_ubuntu-xenial-i386.linux_4.4.0-95.118_BUILDING.txt.gz

Looking at the changes between 4.4.0-94.117 and 4.4.0-95.118 doesn't
show us anything obvious:

  https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/log/?id=5e003b5658bf26a10e58dcf7bef796d05c6bf504&showmsg=1

(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 @@

   User Environment
   ----------------

   APT_CONFIG=/var/lib/sbuild/apt.conf
   DEB_BUILD_OPTIONS=parallel=4
  -HOME=/home/buildd
  +HOME=/sbuild-nonexistent
   LANG=C.UTF-8
   LC_ALL=C.UTF-8
   LOGNAME=buildd
  -MAIL=/var/mail/buildd
  -OLDPWD=/
  -PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
  -PWD=/<<PKGBUILDDIR>>
  +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
  +SCHROOT_ALIAS_NAME=build-PACKAGEBUILD-13347625
  +SCHROOT_CHROOT_NAME=build-PACKAGEBUILD-13347625
  +SCHROOT_COMMAND=env
  +SCHROOT_GID=2501
  +SCHROOT_GROUP=buildd
  +SCHROOT_SESSION_ID=build-PACKAGEBUILD-13347625
  +SCHROOT_UID=2001
  +SCHROOT_USER=buildd
   SHELL=/bin/sh
  -SUDO_COMMAND=/usr/sbin/chroot /<<CHROOT>> su buildd -s /bin/sh -c cd '/<<PKGBUILDDIR>>' && 'env'
  -SUDO_GID=2501
  -SUDO_UID=2001
  -SUDO_USER=buildd
   TERM=unknown
   USER=buildd
  -USERNAME=root
  +V=1

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!

-- 
Steve Beattie
<sbeattie at ubuntu.com>
http://NxNW.org/~steve/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-hardened/attachments/20170922/be1b0539/attachment.sig>