Re: execlineb ELF executable stack on Linux

From: Xavier Stonestreet <xstonestreet_at_gmail.com>
Date: Thu, 8 Apr 2021 19:12:52 +0200

On Thu, Apr 8, 2021 at 2:25 PM Laurent Bercot <ska-skaware_at_skarnet.org> wrote:

> What works is setting the attribute at the link level
> (-Wl,-z,noexecstack in LDFLAGS), and if it's not done, apparently
> GNU toolchains still mark the stack as executable by default in the
> binaries.

Yes that is effective at marking the stack non-executable in the ELF
image, but I'm concerned that may just be hiding the source of this
weird behavior and might break something in the process.

I did a bit more investigation and here are my findings.

1) I think I misunderstood how the kernel warning works. It may only
apply to images that the kernel execve() itself directly rather than
to any execve() syscall.

It turns out that *all* skarnet ELF executables (at least from the
execline, s6, s6-src, s6-linux-init and utmps packages) have an
executable stack. Except one: s6-linux-init-nuke (more on that
further).

2) Simply compiling a Hello World program with gcc without any option
and linked with musl libc produces an executable with a non-executable
stack by default.

3) I went back and triple-checked all objects, static and shared
libraries from execline, skalibs, musl, and gcc. None of them have the
executable stack flag.

readelf -l <file> | grep GNU_STACK on shared libraries shows 'RW' not
'RWE' in the flags column
readelf -S <file> | grep GNU-stack on objects and static libraries
shows no 'X' in the flags column

And yet somehow the resulting skarnet linked executables end up with a
'RWE' GNU_STACK. Very strange.

4) s6-linux-init-nuke's GNU_STACK flags are 'RW' (so not executable)
and it is the only skarnet executable I have built that is not linked
with skalibs!

So it seems there is something in one of the skalibs that tells the
linker to mark the stack as executable. I wish I could tell you what,
but that is beyond my expertise.
Received on Thu Apr 08 2021 - 17:12:52 UTC

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