[PATCH 1/2] aarch64: Lock GCS with glibc.cpu.aarch64_gcs_lock tunable

[Yury Khrustalev]

On Fri, Dec 19, 2025 at 10:17:02AM -0300, Adhemerval Zanella Netto wrote:
> 
> On 19/12/25 10:00, Yury Khrustalev wrote:
> > On Fri, Dec 19, 2025 at 09:20:43AM -0300, Adhemerval Zanella Netto wrote:
> >>
> >>>> ...
> >>>>
> >>>> Because I am not sure tunables is right way to add and enforce security
> >>>> hardening:
> >>>
> >>> This new tunable allows to turn off locking explicitly. By default GCS
> >>> locking is enabled (provided that GCS is activated, of course). So GCS
> >>> is opt-in and GCS-lock is opt-out.
> >>>
> >>> Binary providers (e.g. distros) can choose to patch Glibc to tweak the
> >>> default tunable values to enforce certain behaviour unless it is
> >>> modified through environment in some other way. For now default tunable
> >>> values are chosen to make GCS opt-in. Later we can change it to opt-out.
> >>
> >> My main issue is the tunable requirement, not the GCS locking by default.
> > 
> > We can just lock it unconditionally.
> 
> Yes, that is my position.

Since there is also some opposition to allow userspace to control shadow
stack size [1], some applications might want to choose to execute some
of their threads without GCS in which case they will want to disable GCS
for such threads and will need to disable GCS locking. If we allow at
least some flexibility over shadow stacks, this will not be much of a
problem.

> > 
> >> This kernel bug is *really* annoying, and although the tunable gives users a 
> >> way to overcome it, the question is if we really have a widely GCS deployment
> >> that would really require such workaround.
> > 
> > The aarch64_gcs_lock tunable is NOT a workaround for that bug. Similar
> > to the aarch64_gcs tunable, it allows for flexible deployment of the new
> > security feature to avoid any blockers. It would be a shame if shadow
> > stack would have to be disabled for the whole system simply because one
> > app can't work with it until it's fixed.
> 
> But in this case it is a matter to either not build the binary with GCS
> or use glibc.cpu.aarch64_gcs=0 as stopgap measure.

This will certainly work but could be an overkill.

> > ...

[1]: https://inbox.sourceware.org/libc-alpha/146d9fe7-ef32-4f0d-a2b2-8a36eae1bab7@linaro.org/