Re: [PATCH] Add an internal wrapper for clone, clone2 and clone3

["H.J. Lu" <hjl.tools@gmail.com>]

On Mon, Feb 15, 2021 at 6:27 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * H. J. Lu:
>
> > On Mon, Feb 15, 2021 at 2:43 AM Florian Weimer <fweimer@redhat.com> wrote:
> >>
> >> * H. J. Lu via Libc-alpha:
> >>
> >> > The clone3 system call provides a superset of the functionality of clone
> >> > and clone2.  It also provides a number of API improve ments, including
> >> > the ability to specify the size of the child's stack area which can be
> >> > used by kernel to compute the shadow stack size when allocating the
> >> > shadow stack.  Add:
> >> >
> >> > extern int __clone_internal (struct clone_args *cl_args, size_t size,
> >> >                            int (*__fn) (void *__arg), void *__arg);
> >> >
> >> > to provide an abstract interface for clone, clone2 and clone3.
> >> >
> >> > 1. Simplify stack management for clone by passing stack base and size
> >> > to __clone_internal.
> >> > 2. Consolidate clone vs clone2 differences into a single file.
> >> > 3. Use only __clone_internal to clone a thread.  If clone3 returns -1
> >> > with ENOSYS, __clone_internal will fall back to clone or clone2.
> >> > 4. Add the x86-64 clone3 wrapper.
> >> > 5. Enable the public clone3 wrapper in the future after it has been
> >> > added to add targets.
> >>
> >> What do you think about providing a clone wrapper which reuses the
> >> caller's stack?  That would be useful for a (v)fork-style clone.  This
> >> variant could also be exported because the callback inherits a
> >> semi-valid TCB in this case.
> >
> > Sure.  But all new clone wrappers should support clone3.
>
> Through a single interface?  I'm not entirely convinced that this is

Not a single public interface.  If we want to do it, we should start with
the clone3 wrapper.

> possible/desirable, given the differences in behavior.  There is also
> the matter of seccomp filters, which have trouble reading userspace
> memory.
>

-- 
H.J.