libressl: build libcrypto with noexecstack #66454
For some reason, libcrypto would be built with the executable stack flag set. I found out about this when Nginx failed to load the shared library, because I was running it with
I am not sure why the stack ends up executable; the other shared libraries which are part of LibreSSL do not have this flag set. You can verify this with
I would like to understand where the shared stack requirement came from though. Without knowing where it originates from, it is hard to say what the impact of disabling it is. I did find these threads, which suggest that it is safe to use
Motivation for this change
Nginx built against LibreSSL cannot use
Still, I would like to understand where the requirement came from before merging this.
For some reasons, libcrypto would be built with the executable stack flag set. I found out about this when Nginx failed to load the shared library, because I was running it with MemoryDenyWriteExecute=true, which does not permit executable stacks. I am not sure why the stack ends up executable; the other shared libraries which are part of LibreSSL do not have this flag set. You can verify this with 'execstack -q'. Non-executable stacks should be the default, and from checking some other files, that does appear to be the case. The LibreSSL sources do not contain the string "execstack", so I am not sure what causes the default to be overridden. Adding '-z noexecstack' to the linker flags makes the linker unset the flag. Now my Nginx can load the library, and so far I have not run into other issues.
The libcrypto in
Does Darwin have the concept of an executable stack, or should the flag it be omitted entirely there?
Edit: also, the flag is called
Edit 2: I've changed the flag for Darwin, could you check if this works @risicle?
FWIW, my best guess for the reason this happens is that there is some object file that the linker is bringing in which is, for some reason, NOT marked to include the section
Some initial guesswork inside the source code didn't reveal anything on that note, unfortunately. Probably the best way to verify this theory is to simply run the
(In the mean time I am tentatively approving these changes, since they seem to be correct anyway, and work around a clear deficiency.)
Thanks for the elaborate reply, that clarifies a lot. Your suspicion is spot on, there are a number of
List of those
Edit: while inspecting the
So perhaps we can get it working without
It turns out that libcrypto had an exectuable stack, because it linked some objects without a .note.GNU-stack section. Compilers add this section by default, but the objects produced from .S files did not contain it. The .S files do include a directive to add the section, but guarded behind an #ifdef HAVE_GNU_STACK. So define HAVE_GNU_STACK, to ensure that all objects have a .note.GNU-stack section.
I’ve added a new commit that uses