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

[enh]

On Fri, Dec 19, 2025 at 8:36 AM Yury Khrustalev <yury.khrustalev@arm.com> wrote:
>
> 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.

that sounds like an even more contentious option to me? a per-thread
opt-out is a dangerous thing to leave lying around for your _security_
feature!

> 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/
>