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.
> 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.
> > +++ b/include/linux/sched/task.h
> > @@ -41,6 +41,8 @@ struct kernel_clone_args {
> > ????????void *fn_arg;
> > ????????struct cgroup *cgrp;
> > ????????struct css_set *cset;
> > +???????unsigned long shadow_stack;
>
> Was this ^ left in accidentally? Elsewhere in this patch it is getting
> checked too.
Yes, it's just bitrot from removing the pointer.
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.
otherwise 0 size would be fine: the child may not execute
a call instruction at all.
> > 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).
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On Wed, Nov 15, 2023 at 04:20:12PM +0000, [email protected] 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.
On Wed, 2023-11-15 at 18:43 +0000, Mark Brown wrote:
> > 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.
Hmm, I guess there isn't a way to pass a flag for the initial exec
stack? So probably it should just mirror that behavior. Unless you
think a lot of people would like to skip the default behavior.
And of course we don't have a marker on x86 (TODO with alt shadow
stacks). We could still check for size < 8 if we want it to be a
universal thing.
>
> > otherwise 0 size would be fine: the child may not execute
> > a call instruction at all.
It seems like a special case. Where should the SSP be for the new
thread?
>
> 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.
I didn't realize it was passing its own stack either. I guess the
reason is to avoid stack overflows. But none of the specific reasons
listed in the comments seem to applicable to shadow stacks.
What is the case for stack=sp bit of the logic?
I need to look into this more. My first thought is, passing in a stack
doesn't absolutely mean they want a new shadow stack allocated either.
We are changing one heuristic, for another.
The other thought is, the new behavior in the !CLONE_VM case doesn't
seem optimal. fork has ->stack==0. Then we would be allocating a stack
in only the child's MM and changing the SSP there, and for what reason?
So I don't think we should fully move away from taking hints from the
CLONE flags.
Maybe an alternate could just be to lose the CLONE_VFORK specific stack
sharing logic. CLONE_VM always gets a new shadow stack. I don't think
it would disturb userspace functionally, but just involves more
mapping/unmapping.
The 11/16/2023 00:52, Edgecombe, Rick P wrote:
> On Wed, 2023-11-15 at 18:43 +0000, Mark Brown wrote:
> >
> > > otherwise 0 size would be fine: the child may not execute
> > > a call instruction at all.
>
> It seems like a special case. Where should the SSP be for the new
> thread?
yes it is likely not an interesting case in practice so < 8
can be an error i think.
> > > > > 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.
>
> I didn't realize it was passing its own stack either. I guess the
> reason is to avoid stack overflows. But none of the specific reasons
> listed in the comments seem to applicable to shadow stacks.
while CLONE_VFORK allows the child to use the parent shadow
stack (parent and child cannot execute at the same time and
the child wont return to frames created by the parent), we
want to enable precise size accounting of the shadow stack
so requesting a new shadow stack should work if new stack
is specified.
but stack==0 can force shadow_stack_size==0.
i guess the tricky case is stack!=0 && shadow_stack_size==0:
the user may want a new shadow stack with default size logic,
or (with !CLONE_VM || CLONE_VFORK) wants to use the existing
shadow stack from the parent.
>
> What is the case for stack=sp bit of the logic?
iirc it is not documented in the clone man page what stack=0
means and of course you don't want sp==0 in the vfork child
so some targets sets stack to sp in vfork, others set it 0
and expect the kernel to do the right thing.
this likely does not apply to clone3 where the size has to be
specified so maybe stack==sp does not need special treatment.
> I need to look into this more. My first thought is, passing in a stack
> doesn't absolutely mean they want a new shadow stack allocated either.
> We are changing one heuristic, for another.
yes.
> The other thought is, the new behavior in the !CLONE_VM case doesn't
> seem optimal. fork has ->stack==0. Then we would be allocating a stack
> in only the child's MM and changing the SSP there, and for what reason?
> So I don't think we should fully move away from taking hints from the
> CLONE flags.
only stack!=0 case is tricky. stack==0 means existing shadow stack.
>
> Maybe an alternate could just be to lose the CLONE_VFORK specific stack
> sharing logic. CLONE_VM always gets a new shadow stack. I don't think
> it would disturb userspace functionally, but just involves more
> mapping/unmapping.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On Thu, Nov 16, 2023 at 10:32:06AM +0000, [email protected] wrote:
> The 11/16/2023 00:52, Edgecombe, Rick P wrote:
> > On Wed, 2023-11-15 at 18:43 +0000, Mark Brown wrote:
> while CLONE_VFORK allows the child to use the parent shadow
> stack (parent and child cannot execute at the same time and
> the child wont return to frames created by the parent), we
> want to enable precise size accounting of the shadow stack
> so requesting a new shadow stack should work if new stack
> is specified.
> but stack==0 can force shadow_stack_size==0.
> i guess the tricky case is stack!=0 && shadow_stack_size==0:
> the user may want a new shadow stack with default size logic,
> or (with !CLONE_VM || CLONE_VFORK) wants to use the existing
> shadow stack from the parent.
If shadow_stack_size is 0 then we're into clone() behaviour and doing
the default/implicit handling which is to do exactly what the above
describes.
> > What is the case for stack=sp bit of the logic?
> iirc it is not documented in the clone man page what stack=0
> means and of course you don't want sp==0 in the vfork child
> so some targets sets stack to sp in vfork, others set it 0
> and expect the kernel to do the right thing.
The manual page explicitly says that not specifying a stack means to use
the same stack area as the parent.
> this likely does not apply to clone3 where the size has to be
> specified so maybe stack==sp does not need special treatment.
You'd have to be jumping through hoops to manage to get the same stack
pointer while explicitly specifying a stack with clone3() on
architectures where the stack grows down. I'm not sure there's a
reasonable use case.
The 11/16/2023 12:33, Mark Brown wrote:
> On Thu, Nov 16, 2023 at 10:32:06AM +0000, [email protected] wrote:
> > The 11/16/2023 00:52, Edgecombe, Rick P wrote:
> > > On Wed, 2023-11-15 at 18:43 +0000, Mark Brown wrote:
>
> > while CLONE_VFORK allows the child to use the parent shadow
> > stack (parent and child cannot execute at the same time and
> > the child wont return to frames created by the parent), we
> > want to enable precise size accounting of the shadow stack
> > so requesting a new shadow stack should work if new stack
> > is specified.
>
> > but stack==0 can force shadow_stack_size==0.
>
> > i guess the tricky case is stack!=0 && shadow_stack_size==0:
> > the user may want a new shadow stack with default size logic,
> > or (with !CLONE_VM || CLONE_VFORK) wants to use the existing
> > shadow stack from the parent.
>
> If shadow_stack_size is 0 then we're into clone() behaviour and doing
> the default/implicit handling which is to do exactly what the above
> describes.
sounds good.
> > > What is the case for stack=sp bit of the logic?
>
> > iirc it is not documented in the clone man page what stack=0
> > means and of course you don't want sp==0 in the vfork child
> > so some targets sets stack to sp in vfork, others set it 0
> > and expect the kernel to do the right thing.
>
> The manual page explicitly says that not specifying a stack means to use
> the same stack area as the parent.
not for clone. clone3 yes.
> > this likely does not apply to clone3 where the size has to be
> > specified so maybe stack==sp does not need special treatment.
>
> You'd have to be jumping through hoops to manage to get the same stack
> pointer while explicitly specifying a stack with clone3() on
> architectures where the stack grows down. I'm not sure there's a
> reasonable use case.
ok makes sense.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
The 11/16/2023 12:33, Mark Brown wrote:
> On Thu, Nov 16, 2023 at 10:32:06AM +0000, [email protected] wrote:
> > i guess the tricky case is stack!=0 && shadow_stack_size==0:
> > the user may want a new shadow stack with default size logic,
> > or (with !CLONE_VM || CLONE_VFORK) wants to use the existing
> > shadow stack from the parent.
>
> If shadow_stack_size is 0 then we're into clone() behaviour and doing
> the default/implicit handling which is to do exactly what the above
> describes.
to be clear does clone with flags==CLONE_VM|CLONE_VFORK always
use the parent shadow stack independently of the stack argument?
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On Thu, Nov 16, 2023 at 01:55:07PM +0000, [email protected] wrote:
> The 11/16/2023 12:33, Mark Brown wrote:
> > On Thu, Nov 16, 2023 at 10:32:06AM +0000, [email protected] wrote:
> > > i guess the tricky case is stack!=0 && shadow_stack_size==0:
> > > the user may want a new shadow stack with default size logic,
> > > or (with !CLONE_VM || CLONE_VFORK) wants to use the existing
> > > shadow stack from the parent.
> > If shadow_stack_size is 0 then we're into clone() behaviour and doing
> > the default/implicit handling which is to do exactly what the above
> > describes.
> to be clear does clone with flags==CLONE_VM|CLONE_VFORK always
> use the parent shadow stack independently of the stack argument?
!CLONE_VM rather than CLONE_VM but yes, that's what the clone() and
hence current clone3() behaviour is here.
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
There are mechanisms for disabling this...
On Thu, 2023-11-16 at 15:35 +0000, Mark Brown wrote:
> On Thu, Nov 16, 2023 at 01:55:07PM +0000,
> [email protected] wrote:
> > The 11/16/2023 12:33, Mark Brown wrote:
> > > On Thu, Nov 16, 2023 at 10:32:06AM +0000,
> > > [email protected] wrote:
>
> > > > i guess the tricky case is stack!=0 && shadow_stack_size==0:
> > > > the user may want a new shadow stack with default size logic,
> > > > or (with !CLONE_VM || CLONE_VFORK) wants to use the existing
> > > > shadow stack from the parent.
>
> > > If shadow_stack_size is 0 then we're into clone() behaviour and
> > > doing
> > > the default/implicit handling which is to do exactly what the
> > > above
> > > describes.
>
> > to be clear does clone with flags==CLONE_VM|CLONE_VFORK always
> > use the parent shadow stack independently of the stack argument?
>
> !CLONE_VM rather than CLONE_VM but yes, that's what the clone() and
> hence current clone3() behaviour is here.
"flags & CLONE_VM" gets a new shadow stack, unless also
"flags & CLONE_VFORK". Other flags in there are not consulted for the
logic of whether to create a new shadow stack.
So CLONE_VM|CLONE_VFORK will use the parent shadow stack.
!CLONE_VM will also sort of use the same shadow stack, but it's a COW
one.
Now that I've thought about it more, removing the CLONE_VFORK part of
the logic has several downsides. It is a little extra work to create
and unmap a shadow stack for an operation that is supposed to be this
limited fast thing.
It also will change the SSP(let me know if anyone has a general term we
can use) for the child. So if you have like:
ssp = _get_ssp()
if (!vfork()) {
foo = *ssp;
...
}
...it's awkward edge. In the vfork man page it points to fork which has
the text: "The child process is an exact duplicate of the parent
process except for the following points", which obviously doesn't
include SSP.
Lastly, there are already cases where the x86 glibc implementation
stays on the shadow stack when it switches regular stacks (i.e.
sigaltstack()). vfork children are not supposed to return, so it should
normally work to be on the same shadow stack. So it's not a special
situation unless we can resolve those other situations, which are
limited by the stack lifetime issues.
What about a CLONE_NEW_SHSTK for clone3 that forces a new shadow stack?
So keep the existing logic, but the new flag can override the logic for
!CLONE_VM and CLONE_VFORK if the caller wants. The behavior of
shadow_stack_size is then simple. 0 means use default size, !0 means
use the passed size. No need to overload and tie up args->stack.
In the other direction though... CLONE_VFORK can be used to stay on the
existing shadow stack and possibly corrupt it. This connects with
earlier discussions around signals dropping a token before being
handled and the overflow use case, and trying to guarantee one thread
per shadow stack at a time, etc. So if there is any inclination towards
trying to get that, it might actually be useful for another reason. It
will close one method for getting two threads on the same shadow stack
at the same time (one is sleeping yes, but it's the same problem in
effect).
On Thu, Nov 16, 2023 at 12:52:09AM +0000, Edgecombe, Rick P wrote:
> On Wed, 2023-11-15 at 18:43 +0000, Mark Brown wrote:
> > > 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.
> Hmm, I guess there isn't a way to pass a flag for the initial exec
> stack? So probably it should just mirror that behavior. Unless you
> think a lot of people would like to skip the default behavior.
I don't really know that anyone would particularly want to use a flag on
arm64, I was more thinking for the benefit of x86 where any termination
record would be a change. It's certainly easier to not have flags so
I'm more than happy to leave things as they are, there's nothing
stopping further extensions of the ABI if we decide we want them later.
> And of course we don't have a marker on x86 (TODO with alt shadow
> stacks). We could still check for size < 8 if we want it to be a
> universal thing.
It does seem simpler, size < 8 is all edge case.
On Thu, 2023-11-16 at 18:14 +0000, Mark Brown wrote:
> On Thu, Nov 16, 2023 at 12:52:09AM +0000, Edgecombe, Rick P wrote:
> > On Wed, 2023-11-15 at 18:43 +0000, Mark Brown wrote:
> > > > 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.
>
> > Hmm, I guess there isn't a way to pass a flag for the initial exec
> > stack? So probably it should just mirror that behavior. Unless you
> > think a lot of people would like to skip the default behavior.
>
> I don't really know that anyone would particularly want to use a flag
> on
> arm64, I was more thinking for the benefit of x86 where any
> termination
> record would be a change. It's certainly easier to not have flags so
> I'm more than happy to leave things as they are, there's nothing
> stopping further extensions of the ABI if we decide we want them
> later.
I'm hoping that shifting the shadow stack start by one frame for thread
stacks (where there is no token to find) will not disturb anything. But
for x86, we will need a new elf bit to be fully safe in implementing
alt shadow stack. When we do that we will have a chance to add an end
of stack marker without compatibility issues on x86. So just doing
default behavior seems fine.
For map_shadow_stack, the end of stack marker will shift the token,
which userspace needs to find, so that is why I wanted a flag for that.
Appreciate the consideration.
On Thu, Nov 16, 2023 at 06:11:17PM +0000, Edgecombe, Rick P wrote:
> Now that I've thought about it more, removing the CLONE_VFORK part of
> the logic has several downsides. It is a little extra work to create
> and unmap a shadow stack for an operation that is supposed to be this
> limited fast thing.
It does rather feel like it's defeating the point of the thing.
> It also will change the SSP(let me know if anyone has a general term we
> can use) for the child. So if you have like:
SSP seems fine, we're already using shadow stack here.
> What about a CLONE_NEW_SHSTK for clone3 that forces a new shadow stack?
> So keep the existing logic, but the new flag can override the logic for
> !CLONE_VM and CLONE_VFORK if the caller wants. The behavior of
> shadow_stack_size is then simple. 0 means use default size, !0 means
> use the passed size. No need to overload and tie up args->stack.
That does seem like it cuts through the ambiguous cases. If we go for
that it feels like we should require the flag when specifying a size,
just to be sure that everything is clear. Though having said that we
could just always allocate a shadow stack if a size is specified
regardless of the flags, requiring people who want non-default behaviour
to have some idea what stack size they want. I don't think I have
strong opinons between having the new flag or always allocating a stack
if a size is specified.
On Thu, 2023-11-16 at 18:41 +0000, Mark Brown wrote:
> > What about a CLONE_NEW_SHSTK for clone3 that forces a new shadow
> > stack?
> > So keep the existing logic, but the new flag can override the logic
> > for
> > !CLONE_VM and CLONE_VFORK if the caller wants. The behavior of
> > shadow_stack_size is then simple. 0 means use default size, !0
> > means
> > use the passed size. No need to overload and tie up args->stack.
>
> That does seem like it cuts through the ambiguous cases. If we go
> for
> that it feels like we should require the flag when specifying a size,
> just to be sure that everything is clear. Though having said that we
> could just always allocate a shadow stack if a size is specified
> regardless of the flags, requiring people who want non-default
> behaviour
> to have some idea what stack size they want. I don't think I have
> strong opinons between having the new flag or always allocating a
> stack
> if a size is specified.
Either of those seem fine to me, but it would be nice to get it vetted
by the libc folks before committing. I'd maybe lean towards the one you
suggested without the new flag.
On Fri, Nov 17, 2023 at 05:43:26PM +0000, Edgecombe, Rick P wrote:
> Either of those seem fine to me, but it would be nice to get it vetted
> by the libc folks before committing. I'd maybe lean towards the one you
> suggested without the new flag.
I'll go with just taking the stack size as a parameter then, less
validation, hopefully the userspace people will be OK with that - I
agree it'd be best to get their buy in.