Re: [PATCH][RFA/RFC] Stack clash mitigation patch 01/08 - V3

[Richard Biener <richard dot guenther at gmail dot com>]

On August 23, 2017 6:36:32 PM GMT+02:00, Jeff Law <law@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