The 11/16/2023 12:33, Mark Brown wrote:
> On Thu, Nov 16, 2023 at 10:32:06AM +0000, szabolcs.n...@arm.com 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
The 11/16/2023 12:33, Mark Brown wrote:
> On Thu, Nov 16, 2023 at 10:32:06AM +0000, szabolcs.n...@arm.com wrote:
> > The 11/16/2023 00:52, Edgecombe, Rick P wrote:
> > > On Wed, 2023-11-15 at 18:43 +, Mark Brown wrote:
>
> > while CLONE_VFORK allows the child to use
The 11/16/2023 00:52, Edgecombe, Rick P wrote:
> On Wed, 2023-11-15 at 18:43 +, 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 likel
The 11/15/2023 12:36, Mark Brown wrote:
> On Wed, Nov 15, 2023 at 12:45:45AM +, Edgecombe, Rick P wrote:
> > On Tue, 2023-11-14 at 20:05 +, Mark Brown wrote:
>
> > > + if (size < 8)
> > > + return (unsigned long)ERR_PTR(-EINVAL);
>
> > What is the intenti
The 10/27/2023 16:24, Deepak Gupta wrote:
> On Fri, Oct 27, 2023 at 12:49:59PM +0100, szabolcs.n...@arm.com wrote:
> > no. the lifetime is the issue: a stack in principle can outlive
> > a thread and resumed even after the original thread exited.
> > for that to work th
The 10/27/2023 15:55, Edgecombe, Rick P wrote:
> Do you have any updated plans to share around your earlier ideas for
> token schemes that try to shoot for more compatibility or security?
not really.
i don't like that shadow stack overflow cannot be handled,
so we have to allocate huge shadow sta
The 10/26/2023 13:40, Deepak Gupta wrote:
> On Thu, Oct 26, 2023 at 06:53:37PM +0100, Mark Brown wrote:
> > I'm not sure placement control is essential but the other bit of it is
> > the freeing of the shadow stack, especially if userspace is doing stack
> > switches the current behaviour where we
