On Tue, Feb 20, 2024 at 08:27:37PM -0500, dalias@libc.org wrote:
On Wed, Feb 21, 2024 at 12:35:48AM +0000, Edgecombe, Rick P wrote:
(INCSSP, RSTORSSP, etc). These are a collection of instructions that allow limited control of the SSP. When shadow stack gets disabled, these suddenly turn into #UD generating instructions. So any other threads executing those instructions when shadow stack got disabled would be in for a nasty surprise.
This is the kernel's problem if that's happening. It should be trapping these and returning immediately like a NOP if shadow stack has been disabled, not generating SIGILL.
I'm not sure that's going to work out well, all it takes is some code that's looking at the shadow stack and expecting something to happen as a result of the instructions it's executing and we run into trouble. A lot of things won't notice and will just happily carry on but I expect there are going to be things that care. We also end up with an additional state for threads that have had shadow stacks transparently disabled, that's managable but still.
The place where it's really needed to be able to allocate the shadow stack synchronously under userspace control, in order to harden normal applications that aren't doing funny things, is in pthread_create without a caller-provided stack.
Yea most apps don't do anything too tricky. Mostly shadow stack "just works". But it's no excuse to just crash for the others.
One thing to note here is that, to enable this, we're going to need some way to detect "new enough kernel that shadow stack semantics are all right". If there are kernels that have shadow stack support but with problems that make it unsafe to use (this sounds like the case), we can't turn it on without a way to avoid trying to use it on those.
If we have this automatic conversion of pages to shadow stack then we should have an API for enabling it, userspace should be able to use the presence of that API to determine if the feature is there.