Re: [PATCH 2/2] arm64: gcs: Store GCSCRE0_EL1 values instead of userspace mode

[Catalin Marinas <catalin.marinas@arm.com>]

On Wed, Oct 14, 2026 at 07:28:08PM +0100, Mark Brown wrote:
> On Wed, Oct 14, 2026 at 06:30:10PM +0100, Catalin Marinas wrote:
> > On Thu, Sep 17, 2026 at 11:14:17PM +0100, Mark Brown wrote:
> 
> > >  	u64			por_el0;
> > >  #ifdef CONFIG_ARM64_GCS
> > > -	unsigned int		gcs_el0_mode;
> > > +	unsigned int		gcscre0_el1;
> 
> > u64?
> 
> Sure, I always find the decision about which to use in a given situation
> confusing.

gcs_el0_mode was a software view. gcscre0_el1 is a raw sysreg value,
described in the Arm ARM as 64-bit (though the top bits are RES0).

> > > -	current->thread.gcs_el0_mode = enabled;
> > > +	gcs_set_el0_mode(current, enabled);
> > 
> > I think we have an existing bug here and it's more serious without this
> > patch. restore_gcs_context() does not update the actual register and,
> > with current mainline, we may even skip the hardware write in
> > gcs_thread_switch(). Basically one task can disable GCS for another
> 
> Right, that's an existing bug.
> 
> > task. Can we get gcs_set_el0_mode() to actually update the register as
> > well?
> 
> We also set the mode from ptrace at which point it's being set for a
> different thread.

Could we do like in arch_set_shadow_stack_status() for gcspr_el0 and
only set it if task == current?

> > On the sigreturn bug, do you recall why we thought we needed to update
> > the gcs_el0_mode in the signal handler (or even expose it)? Wouldn't it
> > be better if the signal handler did a prctl() directly if it needed to
> > change the mode for the current thread?
> 
> In theory you could have tasks with a mix of GCS and non-GCS threads
> doing green thread stuff, especially if the clone3() stuff had gone in
> so that the GCS wasn't so tied to the thread.  You could also have mixed
> push or write permissions in that case.  I am not sure that any of this
> is a realistic use case though, I'm certainly not aware of any current
> users. 
> 
> The case where a signal handler tries to handle a GCS fault by disabling
> GCS could be handled using prctl() if someone wants it.  I'm not aware
> of anyone doing that yet, there was some talk about implementing it in
> glibc at LPC but it's not been implemented.

Just thinking, if we fault on a modified field, a handler using prctl()
would also have to update features_enabled in the sigcontext, otherwise
sigreturn fails. I think that is already the case today for disabling
(the frame still has ENABLE, so sigreturn returns -EINVAL). prctl()
changes to WRITE/PUSH are silently reverted.

Another option is to ignore the field on sigreturn and keep it for
information only. I favour the latter, but it needs to be a separate
patch for discussion and a change to the sigreturn text in
Documentation/arch/arm64/gcs.rst.

-- 
Catalin