Re: Avoid two SSP ABI's for AArch64.

[Richard Earnshaw <rearnsha at arm dot com>]

On 07/12/13 15:51, Carlos O'Donell wrote:
> On 12/06/2013 10:31 AM, Richard Earnshaw wrote:
>> On 06/12/13 15:26, Carlos O'Donell wrote:
>>> On 12/06/2013 09:26 AM, Marcus Shawcroft wrote:
>>>> The first sequence is a very common A64 idiom,  while the latter
>>>> sequence is much less common.  From discussion with various
>>>> u-architects I am led to believe that given a range of different
>>>> AArch64 u-architectures each with a unique set of design trade offs,
>>>> the MRS implementation is a best going to have equivalent performance
>>>> to the ADRP, but will be most likely to have the largest variation in
>>>> implementation performance.
>>>>
>>>> My view therefore is that we should run with the __stack_chk_guard
>>>> global data mechanism.
>>>
>>> I appreciate you reaching out to the contacts you have and for making
>>> a decision on this.
>>>
>>> Can I get you to confirm that for AArch64 we're going to use the
>>> global data access mechanism for the stack guard value used by 
>>> the stack smashing code code?
>>>
>>> This means no ABI change for LLVM or GCC.
>>>
>>> Cheers,
>>> Carlos.
>>>
>>>
>>
>> Carlos,
>>
>> It's my understanding that glibc currently supports one model or the
>> other in the code, but not both.
> 
> That is correct.
> 
>> Is there any technical reason why it could not simultaneously support
>> both?  If it did, what would be the cost of doing so?  Simple one-off
>> cost or significant run-time cost?
> 
> There is no technical reason for not supporting both (there are few
> technical reasons ever, it's mostly expert opinion about design).
> 
> At present the most significant cost is maintaining, testing and
> synchronizing the two ABIs.
> 
> If we want to support two ABIs I will strongly oppose any patch that 
> doesn't provide a patch for testing both ABIs and ensuring that
> the build continues to support both ABIs.
> 
> The synchronization at present is easy, set both values to the same
> value at startup. I can't say what will happen in the future or if this
> will limit future design changes. That is another factor and another
> reason for limiting the supported ABIs.
> 
>> I'm not saying that we would want to do that today, but knowing that it
>> was possible would make me happier about taking a relatively finely
>> balanced decision today.
> 
> I would "like" to maintain one SSP ABI per target. That simplifies the
> maintenance, debugging and doesn't limit future design changes.
> 
> If ARM argues eloquently that the optimal ABI per target actually
> depends on micro-architecture variants then that's another question.
> I'm not arguing against such a statement, but I am arguing that we need
> better testing and I'll oppose such changes without due-diligence in
> additional tests for glibc.
> 
> For example it's already the case for 32-bit ARM that newer ARM targets
> might benefit from using TP+offset, but because glibc supports only one
> such SSP ABI we have chosen global symbol as the default. Enabling both
> tp+offset and global symbol might benefit newer 32-bit ARM cores.
> 
> Again, I want to see engineering rigour here, clear performance arguments
> (or claims from experts) and testing improvements for this. We already
> have pointer guard and stack guard tests, but they only test one ABI.
> They need to be recompiled with a distinct set of stackguard-macros.h
> for each SSP ABI variant and re-run as unique tests.
> 
> Does that make sense?
> 

Thanks,

I do not expect to need to change/add the alternative ABI interface, but
knowing that it should be technically possible means I can go forward
with what I believe today to be the correct decision with much more
confidence.

So on that basis I think we should stick with the default ABI -- ie
using __stack_chk_guard.

R.