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.
Attachment:
signature.asc
Description: PGP signature
