[PATCH v8 13/20] aarch64: Add glibc.cpu.aarch64_gcs_policy tunable

[Yury Khrustalev]

On Thu, Jan 16, 2025 at 09:37:37AM -0300, Adhemerval Zanella Netto wrote:
> >>>
> >>> Policy sets how GCS tunable and GCS marking turns into gcs state:
> >>>
> >>> 0: state = tunable
> >>> 1: state = marking ? tunable : (tunable && dlopen ? err : 0)
> >>> 2: state = marking ? tunable : (tunable ? err : 0)
> >>>
> >>
> >> Is the policy '1' really a good semantic? I know that for testing and transition to
> >> GCS enablement it might make sense, but we recently removed the non-executable stack
> >> switch for dynamic shared object through dlopen (0ca8785a28515291d4ef074b5b6cfb27434c1d2b)
> >> because this was used as vector for a RCE.
> >>
> >> I know that is gated through a environment variable, but even though it opens some
> >> possibility to silent disable GCS in a misconfigured environment.
> > 
> > The value 1 is a lenient form of policy to allow applocations that fully
> > support GCS to benefit from it while the apps that have dependencies that
> > don't yet support GCS would continue to work in the same environment. This
> > is indeed to help with transition, and we think this approach is reasonable.
> 
> This is a potentially security issue and I don't think we should allow it

I'm not sure if this is really a security issue as the policy tunable is
controlled via environment variable, so if policy could be somehow set to 1
by an attacker, then this attacker would likely also be able to set the 
glibc.cpu.aarch64_gcs tunable to 0.

> Similar to how now we enforce non-executable stacks, I think we should 
> enforce on program loading, or return an error for dlopen.  Meaning just:
> 
>   0: state = tunable
>   1: state = marking ? tunable : (tunable ? err : 0)

This means that, when glibc.cpu.aarch64_gcs is set, with policy 1 we always
fail if there is marking mismatch **regardless** of loading being via dlopen()
or not.

> It means dlopen will fail if the object does not contain the GCS marking
> if GCS is enabled; which I think is the expected behavior for most deployments.

We already error on dlopen of unmarked library when glibc.cpu.aarch64_gcs is set
with the current implementation for any non-zero policy.

Thanks,
Yury