On Wed, 23 Mar 2022 at 00:02, Christian Brauner <brauner@xxxxxxxxxx> wrote:
>
> On Mon, Mar 21, 2022 at 10:47:49AM +0100, Arnd Bergmann wrote:
> > On Mon, Mar 21, 2022 at 10:41 AM Huacai Chen <chenhuacai@xxxxxxxxxx> wrote:
> > > On Mon, Mar 21, 2022 at 5:01 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
> > > >
> > > > On Sat, Mar 19, 2022 at 3:38 PM Huacai Chen <chenhuacai@xxxxxxxxxx> wrote:
> > > > >
> > > > > This patch adds system call support and related uaccess.h for LoongArch.
> > > > >
> > > > > Q: Why keep __ARCH_WANT_NEW_STAT definition while there is statx:
> > > > > A: Until the latest glibc release (2.34), statx is only used for 32-bit
> > > > > platforms, or 64-bit platforms with 32-bit timestamp. I.e., Most 64-
> > > > > bit platforms still use newstat now.
> > > > >
> > > > > Q: Why keep _ARCH_WANT_SYS_CLONE definition while there is clone3:
> > > > > A: The latest glibc release (2.34) has some basic support for clone3 but
> > > > > it isn't complete. E.g., pthread_create() and spawni() have converted
> > > > > to use clone3 but fork() will still use clone. Moreover, some seccomp
> > > > > related applications can still not work perfectly with clone3.
> > > >
> > > > Please leave those out of the mainline kernel support though: Any users
> > > > of existing glibc binaries can keep using patched kernels for the moment,
> > > > and then later drop those pages when the proper glibc support gets
> > > > merged.
> > > The glibc commit d8ea0d0168b190bdf138a20358293c939509367f ("Add an
> > > internal wrapper for clone, clone2 and clone3") modified nearly
> > > everything in order to move to clone3(), except arch_fork() which used
> > > by fork(). And I cannot find any submitted patches to solve it. So I
> > > don't think this is just a forget, maybe there are other fundamental
> > > problems?
> >
> > I don't think there are fundamental issues, they probably did not consider
> > it necessary because so far all architectures supported clone().
> >
> > Adding Christian Brauner and H.J. Lu for clarificatoin.
>
> Probably, yes. I don't know of any fundamental problems there either.
>
Hi, Arnd, Christian,
As far as I know, software that uses the linux sandbox is still using clone(),
such as chromium:
commit 218438259dd795456f0a48f67cbe5b4e520db88b
Author: Matthew Denton <mpdenton@xxxxxxxxxxxx>
Date: Thu Jun 3 20:06:13 2021 +0000
Linux sandbox: return ENOSYS for clone3
Because clone3 uses a pointer argument rather than a flags argument, we
cannot examine the contents with seccomp, which is essential to
preventing sandboxed processes from starting other processes. So, we
won't be able to support clone3 in Chromium. This CL modifies the
BPF policy to return ENOSYS for clone3 so glibc always uses the fallback
to clone.
Bug: 1213452
Change-Id: I7c7c585a319e0264eac5b1ebee1a45be2d782303
Reviewed-on:
https://chromium-review.googlesource.com/c/chromium/src/+/2936184
Reviewed-by: Robert Sesek <rsesek@xxxxxxxxxxxx>
Commit-Queue: Matthew Denton <mpdenton@xxxxxxxxxxxx>
Cr-Commit-Position: refs/heads/master@{#888980}
Besides arch_fork(), I think removing clone() may lead to more problems.
Thanks,
Feiyang
