+ correct kernel mailing list this time. On Wed, Oct 21, 2020 at 2:33 PM Nick Desaulniers <ndesaulni...@google.com> wrote: > > 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
-- Thanks, ~Nick Desaulniers
