On August 23, 2017 6:36:32 PM GMT+02:00, Jeff Law <l...@redhat.com> wrote: >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.
So the natural thing for LTO ist to make it function granular. That way you don't need any magic in LTO-wrapper. Richard. > >Jeff
