On Thu, Aug 15, 2024 at 04:46:04PM +0100, Mark Brown wrote:

On Thu, Aug 15, 2024 at 04:33:25PM +0100, Dave Martin wrote:

quoted

On Thu, Aug 15, 2024 at 04:05:32PM +0100, Mark Brown wrote:

quoted

quoted

The expectation (at least for arm64) is that the main program will only
have shadow stacks if everything says it can support them.  If the
dynamic linker turns them on during startup prior to parsing the main
executables this means that it should turn them off before actually
starting the executable, taking care to consider any locking of features.

quoted

Hmm, so we really do get a clear "enable shadow stack" call to the
kernel, which we can reasonaly expect won't happen for ancient software?

Yes, userspace always has to explicitly enable the GCS.

quoted

If so, I think dumping the GCS state in the sigframe could be made
conditional on that without problems (?)

It is - we only allocate the sigframe if the task has GCS enabled.

OK, makes sense.

quoted

quoted

quoted

Related question: does shadow stack work with ucontext-based coroutines?
Per-context stacks need to be allocated by the program for that.

quoted

quoted

Yes, ucontext based coroutines are the sort of thing I meant when I was
talking about returning to a different context?  

quoted

Ah, right.  Doing this asynchronously on the back of a signal (instead
of doing a sigreturn) is the bad thing.  setcontext() officially
doesn't work for this any more, and doing it by hacking or rebuilding
the sigframe is extremely hairy and probably a terrible idea for the
reasons I gave.

I see.  I tend to view this as more adventurous than I personally would
be when writing userspace code but equally I don't see a need to
actively break things.  There's no *requirement* to use libc...

quoted

So, overall I think making ucontext coroutines with with GCS is purely
a libc matter that is "interesting" here, but we don't need to worry
about.

Yes, it's not our problem so long as we don't get in the way somehow.

Sure.  "Hairy and probably a terrible idea" is not the same as
"impossible", but you need to know what you're doing and you get
exposed to all sorts of portability challenges.

There's a limit to how much we should attempt to smooth over all that.

Anyway, I think what the GCS patches are doing looks reasonable.

Cheers
---Dave