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

[Yury Khrustalev]

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).

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?

Thanks,
Yury