On Fri, Dec 01, 2023 at 05:30:22PM +0000, Catalin Marinas wrote:
Another concern I had was that map_shadow_stack() currently takes a flags arg (though only one flag) while the clone/clone3() allocate the shadow stack with an implicit configuration (other than size). Would map_shadow_stack() ever get new flags that we may also need to set on the default thread shadow stack (e.g. a new permission type)? At that point it would be better if clone3() allowed a shadow stack pointer so that any specific attributes would be limited to map_shadow_stack().
The flags argument currently only lets you specify if a stack switch token should be written (which is not relevant for the clone3() case) and if a top of stack marker should be included (which since the top of stack marker is NULL for arm64 only has perceptible effect if a token is being written). I'm not particularly anticipating any further additions, though never say never.
If that's only theoretical, I'm fine to go ahead with a size-only argument for clone3(). We could also add the pointer now and allocate the stack if NULL or reuse it if not, maybe with some prctl to allow this. It might be overengineering and we'd never use such feature though.
Yeah, it seems like a bunch of work and interface to test that I'm not convinced anyone would actually use.
As well as the actual configuration of the size the other thing that we gain is that as well as relying on heuristics to determine if we need to allocate a new shadow stack for the new thread we allow userspace to explicitly request a new shadow stack.
But the reverse is not true - we can't use clone3() to create a thread without a shadow stack AFAICT.
Right. Given the existing implicit allocation only x86 ABI we'd need to retrofit that by adding an explicit "no shadow stack" flag. That is possible though I'm having a hard time seeing the use case for it.