execlineb ELF executable stack on Linux

From: Xavier Stonestreet <xstonestreet_at_gmail.com>
Date: Thu, 8 Apr 2021 07:58:26 +0200

Hello,

First I apologize if this is a FAQ. I searched this mailing list
archive and the interweb at large but didn't find anything relevant.

Recent versions of the Linux kernel issue a warning when a process
executes an image with an executable stack, as an indicator of a
_potential_ security vulnerability. Such a warning is issued when
execlineb is executed.

I just noticed it in my kernel logs because I just started using
s6-linux-init and execlineb is the very first executable to run after
the kernel. s6-linux-init is great by the way, I love it -- but that's
a topic for another mailing list :-)

I'm not concerned about the security of execlineb itself in relation
to this warning. I build the kernel and all user-space packages,
including the compiler toolchain, from source code myself, so I would
like to confirm that this is expected and not something specific,
presumably broken, to my setup.

It seems to me the executable stack in execlineb is neither by design
nor by omission but, if my understanding is correct, a byproduct of
the gcc compiler (trampoline code generation for nested functions?). I
noticed that the execline Makefile explicitly forbids making the stack
executable with the -Wa,--noexecstack assembler option, but then the
resulting linked ELF image (statically linked with skalibs, and
dynamically linked with musl) has a GNU_STACK section with the 'E'
(executable) flag.

I double-checked to make sure there might not be musl or gcc objects
with a GNU_STACK marked 'E' that could 'poison' the execlineb
executable.

Thanks.

References:
<https://lore.kernel.org/patchwork/patch/1164047/> Kernel patch for
the warning, and discussion of its pitfalls
<https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks>

My setup:
kernel 5.10.26
musl 1.2.2
gcc 9.3, binutils 2.36.1
skalibs 2.10.0.2
execline 2.8.0.0
all built from source
Received on Thu Apr 08 2021 - 05:58:26 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:38:49 UTC