On Wed, Aug 14, 2024 at 04:09:51PM +0100, Dave Martin wrote:
On Thu, Aug 01, 2024 at 01:06:51PM +0100, Mark Brown wrote:
- if (add_all || task_gcs_el0_enabled(current)) {
err = sigframe_alloc(user, &user->gcs_offset,sizeof(struct gcs_context));if (err)return err;- }
Who turns on GCS? I have a concern that if libc is new enough to be built for GCS then the libc startup code will to turn it on, even if the binary stack running on top of libc is old.
It should normally be the dynamic linker which should be looking for annotatations in the binaries it's loading before it decides if it's going to turn on GCS (and libc doing something similar if it's going to dlopen() things in a process with GCS enabled).
Is there any scenario where it is legitimate for the signal handler to change the shadow stack mode or to return with an altered GCSPR_EL0?
If userspace can rewrite the stack pointer on return (eg, to return to a different context as part of userspace threading) then it will need to be able to also update GCSPR_EL0 to something consistent otherwise attempting to return from the interrupted context isn't going to go well. Changing the mode is a bit more exotic, as it is in general. It's as much to provide information to the signal handler as anything else.
Is the guarded stack considered necessary (or at least beneficial) for backtracing, or is the regular stack sufficient?
It's potentially beneficial, being less vulnerable to corruption and simpler to parse if all you're interested in is return addresses. Profiling in particular was mentioned, grabbing a linear block of memory will hopefully be less overhead than chasing down the stack. The regular stack should generally be sufficient though.