Re: [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3()

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Wed, 2024-08-21 at 13:45 +0100, Mark Brown wrote:
> On Wed, Aug 21, 2024 at 01:45:16AM +0000, Edgecombe, Rick P wrote:
> > On Wed, 2024-08-21 at 01:19 +0100, Mark Brown wrote:
> 
> > > I think it's going to be strange one way or another, either you specify
> > > a size that we don't currently really use or you have two things both
> > > called stacks which are described differently.
> 
> > I would guess users of raw clone3 calls would be able to handle that kind of
> > variation.
> 
> Oh, I'm sure people could cope either way - it's more a question of
> clarity and not causing people go do needless investigations to try to
> figure out what's going on than anything else.

Yes, it won't be a disaster either way.

> 
> > I was just trying to figure out why there is both the pointer and size for
> > normal stacks. It seems that one usage is that you don't have to worry about
> > whether your arch's stack grows up or down. But otherwise, the previous
> > clone's
> > didn't need the size. Before clone3 the stack size users seem to be kernel
> > threads, so when they unified the infrastructure behind kernel_clone_args,
> > stack_size was needed for the struct. Could it be that it just leaked to
> > userspace for that reason? I don't know, but I would think a tweak to such a
> > fundamental syscall should have some purposeful design behind it.
> 
> It's entirely possible it just leaked.  My own attempts to dig through
> the archives haven't turned up anything on the subjecti either, it seems
> to have been there from the get go and just gone in without comment.
> Equally it could just be that people felt that this was a more tasteful
> way of specifying stacks, or that some future use was envisioned.

Ok, well I'm suspicious, but won't object over it. The rest seems settled from
my side. I may try to attract some other x86 attention to that CMPXCHG helper,
but otherwise.

> 
> > >   I suppose we could call
> > > a single parameter shadow_stack_pointer?  Though I do note that as you
> > > indicated we've been going for some time and this is the first time it
> > > came up...
> 
> > Sorry for that. I looked through all the old threads expecting to find
> > discussion, but couldn't find an answer. Is clone3 support a dependency for
> > arm
> > shadow stacks?
> 
> Catalin didn't want to merge the arm64 support without clone3(), and
> there's code dependencies as a result.  I could unpick it and reverse
> the ordering so long as the arm64 maintainers are OK with that since the
> overlap is in the implementation of copy_thread() and some of the
> dependency patches.