https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117434
--- Comment #11 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to kargls from comment #10) > (In reply to Iain Sandoe from comment #9) > > (In reply to kargls from comment #8) > > > (In reply to Iain Sandoe from comment #7) > > > > > > > > /usr/local/bin/ld: warning: /tmp/ccVWAwWh.o: requires executable stack > > > (because the .note.GNU-stack section is executable) > > > > FAOD - does this actually prevent the executable from running - or is it > > that your platform is (correctly) pointing out that executable stack can be > > considered a security risk? > > > > Perhaps your static linker has some option that would prevent that warning, > > is the man-page visible online? > > The compiled executable still runs of my FreeBSD system. I have > > % which ld > /usr/local/bin/ld > % ld --version > GNU ld (GNU Binutils) 2.40 > > Looking at ld.info, I see a '-z execstack' option. > > % gfcx -o z -z execstack y.f90 > % ./z > > No warning appears. I also find > > % gfcx -o z -z noexecstack -save-temps y.f90 > % ./z > > produces no warning and the compiled executable still run. OK So we have a way forward to add specs to suppress the warning if/when we would want to do it. > I suppose the question then comes down to where does the > > .section .note.GNU-stack,"x",@progbits > > come from in the z-y.s save-temps file. There's nothing unexpected here. It comes from the requirements of the trampoline - which is used to call a nested function via a function pointer. What (the GCC default) edition of the nested function support does is to build a small piece of executable code on the stack that is written from a template (but includes the runtime-variable addresses required to call the target function). For some platforms use of executable stack is warned (what you see) and for some it's forbidden (e.g. arm64 Darwin). In the case that we have a warning we can choose to filter it or suppress it. If you consider that the warning should be treated as significant, then there's an alternate implementation for the trampoline which places the executable fragment on the heap (we can then regulate when that heap page is writeable to be mutually exclusive with when it's executable) - which provides a measure more of security than the blanket enable on the stack. To use this means implementing a couple of builtin functions in libgcc and then dealing with enabling it. I don't know exactly what would be required for *BSD .. but it's probably not wildly different from Linux or Darwin - and we've implemented it on both of those.
