On Tue, Oct 20, 2020 at 5:19 AM Richard Biener <richard.guent...@gmail.com> wrote: > > On Tue, Oct 20, 2020 at 1:24 PM Martin Liška <mli...@suse.cz> wrote: > > > > PING^5 > > So can we use the same identifier as clang here as Nick > requests? Thus, OK with re-naming everything alongside > no_stack_protector. It isn't really the opposite of the > stack_protect attribute since that only protects when > -fstack-protector-explicit is enabled.
I'll be happy to help test and review with an updated/rebased patch. Tangentially related question: We're running into a bug related to LTO for the kernel when code compiled with -fno-stack-protector is called from and inlined into code that is compiled with -fstack-protector. Specifically, stack canaries get checked before they're restored post suspend/resume which leads to spooky bugs. Once we have more fine grain function level attribute to explicitly disable stack protectors on a per function basis, I'm considering making this function attribute a barrier to inlining in LLVM so that callers with stack protectors don't inline callees that explicitly should not have a stack protector and vice versa (more concretely, when they don't match). I think this would maximize which functions are still covered by stack protectors, and be the most straightforward to implement. The next question then is what happens when the callee is marked __attribute__((always_inline))? My answer for LLVM currently is "still disallow inline substitution" which is more surprising than I'd like, but we already have precedent for "always inline" not meaning "always." Warning from the frontend when mixing no_stack_protector and always_inline is possible if the callers are visible and don't match, but I don't think that works for cross translation unit calls. I guess I was curious if others have ideas for solutions to this particular problem? Otherwise I plan to implement the above logic in LLVM. We'd eventually need matching logic in GCC to support LTO kernels not having the same bug. https://reviews.llvm.org/D87956 -- Thanks, ~Nick Desaulniers
