On Wed, Nov 15, 2023 at 04:20:12PM +0000, Szabolcs.Nagy@xxxxxxx wrote: > The 11/15/2023 12:36, Mark Brown wrote: > > On Wed, Nov 15, 2023 at 12:45:45AM +0000, Edgecombe, Rick P wrote: > > > On Tue, 2023-11-14 at 20:05 +0000, Mark Brown wrote: > > > > + if (size < 8) > > > > + return (unsigned long)ERR_PTR(-EINVAL); > > > What is the intention here? The check in map_shadow_stack is to leave > > > space for the token, but here there is no token. > > It was to ensure that there is sufficient space for at least one entry > > on the stack. > end marker token (0) needs it i guess. x86 doesn't currently have end markers. Actually, that's a point - should we add a flag for specifying the use of end markers here? There's code in my map_shadow_stack() implementation for arm64 which does that. > otherwise 0 size would be fine: the child may not execute > a call instruction at all. Well, a size of specifically zero will result in a fallback to implicit allocation/sizing of the stack as things stand so this is specifically the case where a size has been specified but is smaller than a single entry. > > > I think for CLONE_VM we should not require a non-zero size. Speaking of > > > CLONE_VM we should probably be clear on what the expected behavior is > > > for situations when a new shadow stack is not usually allocated. > > > !CLONE_VM || CLONE_VFORK will use the existing shadow stack. Should we > > > require shadow_stack_size be zero in this case, or just ignore it? I'd > > > lean towards requiring it to be zero so userspace doesn't pass garbage > > > in that we have to accommodate later. What we could possibly need to do > > > around that though, I'm not sure. What do you think? > > Yes, requiring it to be zero in that case makes sense I think. > i think the condition is "no specified separate stack for > the child (stack==0 || stack==sp)". > CLONE_VFORK does not imply that the existing stack will be > used (a stack for the child can be specified, i think both > glibc and musl do this in posix_spawn). That also works as a check I think, though it requires the arch to check for the stack==sp case - I hadn't been aware of the posix_spawn() usage, the above checks Rick suggested just follow the handling for implicit allocation we have currently.
Attachment:
signature.asc
Description: PGP signature
