Is the execstack flag required on any of the shared libraries?

[JamesKingdon]

A customer reports failures of the JVM when running with SELinux enabled and configured to disallow execstack. The problem occurs because libj9jit29.so and libj9vm29.so are both flagged as requiring execstack. As an experiment I cleared the flag on both libraries and was able to run -version and a standard benchmark without problems. Is it possible that these libraries have been flagged in error?

I tested using Java 17.0.12.1 where both libraries are marked:

# execstack -q *.so
- libcuda4j29.so
- libj9dmp29.so
- libj9gc29.so
- libj9gcchk29.so
- libj9gcchk_full29.so
- libj9gc_full29.so
- libj9hookable29.so
- libj9jextract.so
X libj9jit29.so
- libj9jnichk29.so
- libj9jvmti29.so
- libj9prt29.so
- libj9shr29.so
- libj9thr29.so
- libj9trc29.so
X libj9vm29.so
- libj9vmchk29.so
- libj9vrb29.so
- libj9vrb_full29.so
- libj9zlib29.so
- libjclse29.so
- libjvm.so
- libmanagement_ext.so
- libomrsig.so

and also with ibm sdk 8.0.8.30 where only the jit library is affected. As a footnote, there is also at least one library in WebSphere that has the same problem.

[pshipton]

I don't think it's explicitly set, since I can't find it in the code. I did find some occurrences of -noexecstack related to assembly options. I think either we're missing some, or GCC is setting it. I'm not sure atm how we track down which object file(s) set it.

I found this in the doc:
...
Furthermore, GCC trampoline code for e.g. nested functions requires executable stack on many architectures.
...
The marking is done automatically by recent GCC versions (objects using trampolines on the stack are marked as requiring executable stack, all other newly built objects are marked as not requiring it) and linker collects these markings into marking of the whole binary or shared library.

[pshipton]

Are your execstack results from zlinux? I looked on X and while jit has it, vm does not.

[jdmpapin]

From searching around, apparently when we link with object files produced from assembly sources (.s), those object files are assumed to potentially require executable stack unless they have a special section .note.GNU-stack to explicitly specify stack permissions.

The VM has this (somewhat) recent change, which might prevent newer VM libraries from indicating a need for executable stack. I think it was done to avoid the warning that was introduced in binutils 2.39:

ld: warning: <foo>.o: missing .note.GNU-stack section implies executable stack
ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker

Maybe the JIT still has some assembly sources that are missing the magic incantation.

The JIT library that I most recently built on my system doesn't demand executable stack, but it seems to be due to a difference in the behaviour of the ld installed on my system. I wrote a trivial .c file and a trivial .s file without a .note.GNU-stack section. If I link them with my installed ld, I get no warning and the stack is not executable. It says its version is "GNU ld version 2.43.1-5.fc41". But it so happens that I downloaded the binutils-2.43.1 source a while ago, and if I link them with that, I do get the warning and the stack is executable. So it seems like Fedora has essentially set -z noexecstack by default, or maybe more likely they've just stopped having the missing section imply executable stack, like the warning says will eventually happen.

[JamesKingdon]

Are your execstack results from zlinux? I looked on X and while jit has it, vm does not.

I was testing on X linux

[jdmpapin]

I've seen the same as Peter in a few builds with and without #20278, so apparently something else was already making sure that the VM library wouldn't have executable stack, at least at the time when that went in

[JamesKingdon]

Interesting. I checked the ones I have quickly available;
certified 17.0.12.1: jit and jvm libs both flagged
open 17.0.10_7, 17.0.11_9, 17.0.12_7: both flagged
open 17.0.13_11: only the jit library is flagged