On 8/3/22 12:06 PM, Nick Desaulniers wrote: >> ld: warning: arch/x86/boot/compressed/efi_thunk_64.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 > > Right, arch/x86/boot/compressed (and arch/x86/boot/) discard/reset > KBUILD_AFLAGS (via the := assignment operator). > > So arch/x86/boot/Makefile and arch/x86/boot/compressed/Makefile also > will need changes similar to the one you did below. > > Finally, if those parts of the code actually expect the stack to be > executable (probably depends on some inline asm), I suspect we might > get some kind of fault at runtime (though I don't know how the kernel > handles segment permissions or even uses ELF segments). Point being > that -Wa,--noexecstack is somewhat a promise that we wont try to > execute data on the stack as if it were code. -Wa,--execstack is > useful if we need to be able to do so, but we should be careful to > limit that to individual translation units if they really truly need > that. The linker warning is more so about the current ambiguity since > if the implicit default changes in the future, that could break code. > Better for us to be explicit here, and disable executable stack unless > strictly necessary and only as necessary IMO. Personally, I think the > current implicit default is wrong, but pragmatically I recognize that > people have been used to the status quo for years, and changing it > could break existing codebases. > > If you send the below diff with the two other additions I suggest to > the x86 ML, the x86 maintainers might be able to comment if they're > familiar with any possible cases where the stack is expected to be > executable. I'd be happy for you to take this over, I'm really just the reporter here... -- Jens Axboe
