On Thu, Aug 15, 2024 at 04:33:25PM +0100, Dave Martin wrote:
On Thu, Aug 15, 2024 at 04:05:32PM +0100, Mark Brown wrote:
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.
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.
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.
Related question: does shadow stack work with ucontext-based coroutines? Per-context stacks need to be allocated by the program for that.
Yes, ucontext based coroutines are the sort of thing I meant when I was talking about returning to a different context?
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...
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.