OpenSSL: Link with -znoexecstack when using ld.bfd.

[jhb]

Summary

ld.bfd >= 2.39 emits warnings if input object files do not have
note.GNU-stack annotations requesting a non-executable stack. It is
not feasible to patch all of the assembly files from OpenSSL to add
this annotation as a local patch, so tell the linker to assume the
stack is non-executable instead.

[jhb]

This fixes linking libcrypto.so with GCC 12.

[emaste]

Is this actually an openssl bug, generating these files without the annotation? (E.g., upstream build infra thinks they are required only on Linux?)

I think I'd rather we just set it in LDFLAGS (also for lld)

[emaste]

(But no objection to this as an immediate-term fix)

[jhb]

Yes, OpenSSL will care once Linux distributions upgrade to ld.bfd 2.39 and presumably they will fix it at some point.

However, I think LLD just doesn't care and always assumes -znoexectsack on FreeBSD. Arguably we should just globally add -Wl,-znoexecstack to LDFLAGS for bfd instead of patching it piecemeal.

[emaste]

From lld's docs, "Some default settings have been tuned for the 21st century. For example, the stack is marked as non-executable by default to tighten security."

Arguably we should just globally add -Wl,-znoexecstack to LDFLAGS for bfd instead of patching it piecemeal.

Yeah, I'd be happy to have that change go in.

[jhb]

In D41102#935864, @emaste wrote:

From lld's docs, "Some default settings have been tuned for the 21st century. For example, the stack is marked as non-executable by default to tighten security."

Arguably we should just globally add -Wl,-znoexecstack to LDFLAGS for bfd instead of patching it piecemeal.

Yeah, I'd be happy to have that change go in.

I've tested this as an alternative and posted it as D41120