On 08/23/2017 03:07 AM, Richard Biener wrote: >>> Both -fstack-clash-protection and -fstack-check cannot be turned >>> off per function. This means they would need merging in lto-wrapper. >>> The alternative is to mark them with 'Optimization' and allow per-function >>> specification (like we do for -fstack-protector). >> Do you have a strong preference here? I'd tend to go with tweaking >> lto-wrapper as we really don't want to have this stuff varying per-function. > > Any reason? I see no technical one at least, it might break IPA assumptions > you make when instrumenting? I guess you just don't want to think about > the implications when mixing them (or mixing -fstack-clash-protection > with -fno-stack-clash-protection)? On some targets (s390 for example), a stack guard jump can be accomplished by a combination of caller and callee stack adjustments -- even though neither the caller nor the callee have a large enough adjustment individually to jump the guard.
So a mis-informed developer could audit their code, declare various functions as safe & turn off protections on a per-function basis based on that analysis. But that would be mis-guided as it opens them up to a potential attack where the combination of caller and callee stack adjustments are used to jump the guard. > >> Presumably in lto-wrapper we just have to detect that both were enabled >> and do something sensible. We drop -fstack-check in toplev.c when both >> are specified, we could just as easily call that situation a fatal error >> in both toplev.c and lto-wrapper.c > > So what happens if you LTO link Ada (-fstack-check) with C > (-fstack-clash-protection)? When in the Ada code you'll be mostly protected from stack clashes and you can detect stack overflows and catch the signal properly. When in C code, you'd be fully protected from stack clash, but not necessarily able to take a signal. At the boundaries where you call from Ada to C, you're potentially vulnerable to stack clash on architectures like aarch64/s390. When calling from C into Ada, you're not guaranteed to be able to handle a signal when you overflow the stack. > The user is already allowed to (without LTO) specify things on a CU granularity. True. And you end up with a mixture of protections depending on what code is executing or what boundary you're crossing. Jeff
