Re: [PATCH] [GLIBC RFC] clone3: add CLONE3_RESET_SIGHAND

[Florian Weimer <fweimer at redhat dot com>]

* Christian Brauner:

> Ok, I need to be annoying once more. (As if there wasn't enough of that
> already...)
> So kernel-side a good friend of mine - Aleksa - and I are on the way to
> push through _some_ standards... That very much includes how we check
> for new extensions in syscalls. So we just discussed my earlier proposal
> (Sorry for the lag the distance Australia to Germany makes things a bit
> difficult.). One problem we'll have with adding a new member is that we
> arguably need one for each additional flag member we add. That means
> we'd need:
>
> struct clone_args /* initial struct */ {
> 	__aligned_u64 flags;
> 	__aligned_u64 supported_flags;
> }
>
> and later
>
> struct clone_args /* extended struct: new flags argument added */ {
> 	__aligned_u64 flags;
> 	__aligned_u64 supported_flags;
> 	__aligned_u64 flags2;
> 	__aligned_u64 supported_flags2;
> }
>
> which is not ideal. So we were thinking about a different protocol for
> syscalls which embedd flags arguments in structs.

Is that really a bad problem?

> We'd introduce a new flag
>
> #define SYSCALL_CHECK_FLAGS ((1 << 63)ULL)
>
> that can be used by e.g. clone3() and openat2(). Then you can call the
> syscall with:
>
> struct clone_args args = {
> 	.flags |= SYSCALL_CHECK_FLAGS,
> };
> pid = clone3(&args, sizeof(args));
>
> /* 
>  * The kernel now sets all flags it supports in _all_ flags arguments
>  * present in the struct.
>  */
>
> SYSCALL_CHECK_FLAGS is only valid in the initial flags argument not in
> any added flags arguments.
> If SYSCALL_CHECK_FLAGS is not supported then you'll get EINVAL and the
> SYSCALL_CHECK_FLAGS flag is still present in the flags argument of the
> struct. If it is supported it'll be masked out and all supported flag
> bits will be set by the kernel in _all_ flag arguments that are present
> in the structure.
> Florian, thoughts?

Will SYSCALL_CHECK_FLAGS be for probing only and not perform any action
at all?  I mean, it behaves like this on older kernels due to the EINVAL
error.

I'm not yet decided if we'll need a separate system call wrapper for
cloning on the same stack, for safe(r) use with vfork.  If we do, we'll
have to teach the wrapper about SYSCALL_CHECK_FLAGS, too, I think.  If
a call with SYSCALL_CHECK_FLAGS and all supported flags performs the
requested clone action, that would be easier for us.  But I don't know
if that makes a convenient interface for programmers.

Thanks,
Florian