Thanks for the quick feedback! On Wed, Oct 21, 2020 at 2:13 PM Jakub Jelinek <ja...@redhat.com> wrote: > > On Wed, Oct 21, 2020 at 02:04:15PM -0700, Nick Desaulniers via Gcc-patches > wrote: > > 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. > > That doesn't make sense to me. > Stack protector doesn't affect in any way inlined code, the stack protection > is always solely in the prologue and epilogue of out of line functions. > So, if the (non-inlined) caller is -fstack-protector and inlined callee > is -fno-stack-protector, there should be ssp store in the prologue of the > resulting function and test in the epilogue.
That is the case today, and I'm arguing that leads to bugs in the Linux kernel when built with LTO. > The effect will be exactly > like that if the function wouldn't be inlined. I don't follow. If the -fno-stack-protector callee was not inlined, the caller would have a stack protector, while the callee would not. I think today there's not a strong enough distinction between the level of stack protection being specified vs explicit annotations/flags that stack protectors MUST NOT be inserted. > Similarly, if the non-inlined caller is -fno-stack-protector and inlined > callee is -fstack-protector, there will be no stack protection. This isn't And I'd argue that now we may have stripped off stack protection in the pursuit of inlining. Consider for example the case where that stack protected callee contained a large alloca; post inlining into a -fno-stack-protected caller suddenly now it doesn't. Oops? Wouldn't it be safer to just prevent inlining, then the callee retains the stack protector, regardless of caller stack protection? > exactly the effect one would get without the inlining (as in that case > the callee would check it), but matches the general behavior that we allow > inlining functions with -fstack-protector* at all (and only check it in the > prologue/epilogue, not somewhere in the middle). > > Jakub > -- Thanks, ~Nick Desaulniers
