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

[Mark Brown]

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.

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

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

> I don't think we have any precedent for allowing sigreturn to update an
> EL1 sysreg. In hindsight, we shouldn't have exposed it at all but that's
> ABI now. The next best thing we can do now is check the field hasn't
> been modified and fault otherwise (assuming no-one does anything with
> this field).

I don't think userspace is doing anything with it at present.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20261014/7123ef24/attachment.sig>