[PATCH 11/12] aarch64: redefine RETURN_ADDRESS to strip PAC

[Florian Weimer]

* Adhemerval Zanella:

> On 11/05/2020 16:21, Florian Weimer wrote:
>> * Adhemerval Zanella via Libc-alpha:
>> 
>>> On 11/05/2020 09:38, Szabolcs Nagy wrote:
>>>> The 05/08/2020 14:44, Adhemerval Zanella via Libc-alpha wrote:
>>>>> On 30/04/2020 14:45, Szabolcs Nagy wrote:
>>>>>> +++ b/sysdeps/aarch64/sysdep.h
>>>>>> @@ -35,6 +35,16 @@
>>>>>>  
>>>>>>  #define PTR_SIZE	(1<<PTR_LOG_SIZE)
>>>>>>  
>>>>>> +/* Strip pointer authentication code from pointer p.  */
>>>>>> +#define XPAC(p) ({					\
>>>>>> +  register void *__ra asm ("x30") = (p);		\
>>>>>> +  asm ("hint 7 // xpaclri" : "+r"(__ra));		\
>>>>>> +  __ra;})
>>>>>> +
>>>>>> +/* This is needed when glibc is built with -mbranch-protection=pac-ret.  */
>>>>>> +#undef RETURN_ADDRESS
>>>>>> +#define RETURN_ADDRESS(n) XPAC(__builtin_return_address(n))
>>>>>> +
>>>>>
>>>>> Maybe use a inline function instead?
>>>>
>>>> macro seems more reliable to me than always_inline
>>>> when poking at __builtin_return_address and x30,
>>>> but i'm not against always_inline if that's
>>>> considered better.
>>>
>>> I would prefer a static inline unless a macro is really required
>>> (either due some compiler limitation or bug).
>> 
>> I think __builtin_return_address is ill-defined: Does the frame count
>> that vanishes due to inlining?
>> 
>> So it's probably a case similar to alloca, where a macro has to be
>> used.
>
> This is at least what documentation states [1]:
>
> "When inlining the expected behavior is that the function returns the address 
> of the function that is returned to. To work around this behavior use the 
> noinline function attribute."
>
> [1] https://gcc.gnu.org/onlinedocs/gcc/Return-Address.html

Hmm, okay.  It's still weird not to count those frames, but at least
it's documented.