On Thu, Apr 8, 2021 at 9:57 PM Laurent Bercot <ska-skaw...@skarnet.org> wrote: > > My toolchain also creates E stack binaries by default, no matter > whether they're static or dynamic. It may be that my build of musl is > bad.
That's unexpected. > I am not interested enough in the details of what happens at the ld > level to try and figure out if there's *something* that causes it to > mark E stack when it should not; it requires spending much more > quality time with binutils than I am comfortable with. All I know is > that none of the object files in my software needs E stack, and > bullying ld into doing the right thing works, so I'm content with that > solution. Fair enough. That's totally fine for self-contained packages in which you control the build parameters from end-to-end. This may become an issue with skarnet libraries, such as utmps, that are used with other, non-skarnet packages. Libutmps pulls in libskarnet and libskarnet 'pollutes' the other packages by making their stack executable. I'm currently going through the process of linking some packages (e.g. coreutils, util-linux, and the like) with libutmps, and now the executables that call libutmps have their stack executable. I can deal with it on my own by tweaking the LDFLAGS (-noexecstack) of those packages, it's not too much of an issue for me. But let's take Alpine Linux for example. I see that they now link coreutils, and probably other packages I didn't check, with libutmps and libskarnet. I don't know if they're affected by the same GNU_STACK weirdness in skalibs, or if they scan their distribution binaries for executable stacks, but they may be shipping a bunch of innocuous-looking binaries that have an executable stack and may be vulnerable as a result. So IMHO it may be worthwhile spending some time at some point to figure out what's going on and eventually make it not happen anymore. Just my 2 cents.
