[PATCH v7 13/23] aarch64: Enable GCS in dynamic linked exe

[Adhemerval Zanella Netto]

On 08/01/25 13:54, Yury Khrustalev wrote:
> On Wed, Jan 08, 2025 at 11:04:48AM -0300, Adhemerval Zanella Netto wrote:
>>
>>
>> On 08/01/25 10:52, Yury Khrustalev wrote:
>>> On Tue, Jan 07, 2025 at 01:50:41PM -0300, Adhemerval Zanella Netto wrote:
>>>>
>>>>> +	/* Enable GCS before user code runs.  Note that IFUNC resolvers and
>>>>> +	   LD_AUDIT hooks may run before, but should not create threads.  */
>>>>> +#define PR_SET_SHADOW_STACK_STATUS  75
>>>>> +#define PR_SHADOW_STACK_ENABLE      (1UL << 0)
>>>>> +	mov	x0, PR_SET_SHADOW_STACK_STATUS
>>>>> +	mov	x1, PR_SHADOW_STACK_ENABLE
>>>>> +	mov	x2, 0
>>>>> +	mov	x3, 0
>>>>> +	mov	x4, 0
>>>>> +	mov	x8, #SYS_ify(prctl)
>>>>> +	svc	0x0
>>>>
>>>> Should it handle errors, for the case prctl is filtered or blocked?
>>>
>>> There is no need to handle errors here. If this syscall doesn't succeed, it
>>> would be the same as if we didn't make it at all: GCS will remain disabled.
>>>
>>> Having a check for error here would be an unnecessary overhead.
>>
>> But this is aaik not how other security hardening work, like BTI where 
>> _dl_bti_check will _dl_fatal_printf if bti can not be enabled.  Without a 
>> check, GCS is taking as a hint, not as enforcement
> 
> The _dl_bti_check and _dl_gcs_check functions do something different: they check
> consistency of markings in the binaries and dependencies. Here we are trying to
> enable GCS support (in case of BTI there is no need for this as this is handled
> by kernel).

Yes, my point is kernel enforces BTI/PAC during process execution; while for GCS
this should be enforced by the program loader.  I am not sure if this is really
a security issue, since to force a prctl failure here would require a syscall
interception; but it fells strange that a misconfigured environment (such as
old container runtime or alike) can disable GCS usage.

> 
> We could check the value returned from syscall and call a function that would
> print error message and exit using _dl_fatal_printf.
> 
> I suppose the same should be done for static executables? We'd need to check
> return value of the prctl syscall in aarch64_libc_setup_tls. Is it OK to call
> _dl_fatal_printf in aarch64_libc_setup_tls?

I think it should be, at least with a rapid test by issuing _dl_fatal_printf
unconditionally, static tests does print the message.

> 
> Thanks,
> Yury
>