On 08/23/2017 10:39 AM, Richard Biener wrote:
> 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.
Done.
jeff
