mailing list of musl libc
 help / color / mirror / code / Atom feed
* [musl] Re: [PATCH V9 13/24] LoongArch: Add system call support
       [not found]           ` <20220509100058.vmrgn5fkk3ayt63v@wittgenstein>
@ 2022-05-11  7:11             ` Arnd Bergmann
  2022-05-11 21:12               ` Rich Felker
  0 siblings, 1 reply; 4+ messages in thread
From: Arnd Bergmann @ 2022-05-11  7:11 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Arnd Bergmann, Huacai Chen, Huacai Chen, Andy Lutomirski,
	Thomas Gleixner, Peter Zijlstra, Andrew Morton, David Airlie,
	Jonathan Corbet, Linus Torvalds, linux-arch,
	open list:DOCUMENTATION, Linux Kernel Mailing List, Xuefeng Li,
	Yanteng Si, Guo Ren, Xuerui Wang, Jiaxun Yang, Linux API,
	GNU C Library, musl

On Mon, May 9, 2022 at 12:00 PM Christian Brauner <brauner@kernel.org> wrote:
....
> I can try and move a poc for this up the todo list.
>
> Without an approach like this certain sandboxes will fallback to
> ENOSYSing system calls they can't filter. This is a generic problem
> though with clone3() being one promiment example.

Thank you for the detailed reply. It sounds to me like this will eventually have
to get solved anyway, so we could move ahead without clone() on loongarch,
and just not have support for Chrome until this is fully solved.

As both the glibc and musl ports are being proposed for inclusion right
now, we should try to come to a decision so the libc ports can adjust if
necessary. Adding both mailing lists to Cc here, the discussion is archived
at [1].

         Arnd

[1] https://lore.kernel.org/linux-arch/20220509100058.vmrgn5fkk3ayt63v@wittgenstein/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [musl] Re: [PATCH V9 13/24] LoongArch: Add system call support
  2022-05-11  7:11             ` [musl] Re: [PATCH V9 13/24] LoongArch: Add system call support Arnd Bergmann
@ 2022-05-11 21:12               ` Rich Felker
  2022-05-12  7:21                 ` Arnd Bergmann
  0 siblings, 1 reply; 4+ messages in thread
From: Rich Felker @ 2022-05-11 21:12 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Christian Brauner, Huacai Chen, Huacai Chen, Andy Lutomirski,
	Thomas Gleixner, Peter Zijlstra, Andrew Morton, David Airlie,
	Jonathan Corbet, Linus Torvalds, linux-arch,
	open list:DOCUMENTATION, Linux Kernel Mailing List, Xuefeng Li,
	Yanteng Si, Guo Ren, Xuerui Wang, Jiaxun Yang, Linux API,
	GNU C Library, musl

On Wed, May 11, 2022 at 09:11:56AM +0200, Arnd Bergmann wrote:
> On Mon, May 9, 2022 at 12:00 PM Christian Brauner <brauner@kernel.org> wrote:
> .....
> > I can try and move a poc for this up the todo list.
> >
> > Without an approach like this certain sandboxes will fallback to
> > ENOSYSing system calls they can't filter. This is a generic problem
> > though with clone3() being one promiment example.
> 
> Thank you for the detailed reply. It sounds to me like this will eventually have
> to get solved anyway, so we could move ahead without clone() on loongarch,
> and just not have support for Chrome until this is fully solved.
> 
> As both the glibc and musl ports are being proposed for inclusion right
> now, we should try to come to a decision so the libc ports can adjust if
> necessary. Adding both mailing lists to Cc here, the discussion is archived
> at [1].
> 
>          Arnd
> 
> [1] https://lore.kernel.org/linux-arch/20220509100058.vmrgn5fkk3ayt63v@wittgenstein/

Having read about the seccomp issue, I think it's a very strong
argument that __NR_clone should be kept permanently for all future
archs. Otherwise, at least AIUI, it's impossible to seccomp-sandbox
multithreaded programs (since you can't allow the creation of threads
without also allowing other unwanted use of clone3). It sounds like
there's some interest in extending seccomp to allow filtering of
argument blocks like clone3 uses, but some of what I read about was
checksum-based (thus a weak hardening measure at best, not a hard
privilege boundary) and even if something is eventually created that
works, it won't be available right away, and it won't be nearly as
easy to use as just allowing thread-creating clone syscalls on
existing archs.

Rich

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [musl] Re: [PATCH V9 13/24] LoongArch: Add system call support
  2022-05-11 21:12               ` Rich Felker
@ 2022-05-12  7:21                 ` Arnd Bergmann
  2022-05-12 12:11                   ` Rich Felker
  0 siblings, 1 reply; 4+ messages in thread
From: Arnd Bergmann @ 2022-05-12  7:21 UTC (permalink / raw)
  To: musl
  Cc: Arnd Bergmann, Christian Brauner, Huacai Chen, Huacai Chen,
	Andy Lutomirski, Thomas Gleixner, Peter Zijlstra, Andrew Morton,
	David Airlie, Jonathan Corbet, Linus Torvalds, linux-arch,
	open list:DOCUMENTATION, Linux Kernel Mailing List, Xuefeng Li,
	Yanteng Si, Guo Ren, Xuerui Wang, Jiaxun Yang, Linux API,
	GNU C Library

On Wed, May 11, 2022 at 11:12 PM Rich Felker <dalias@libc.org> wrote:
> On Wed, May 11, 2022 at 09:11:56AM +0200, Arnd Bergmann wrote:
> > On Mon, May 9, 2022 at 12:00 PM Christian Brauner <brauner@kernel.org> wrote:
> > .....
> > > I can try and move a poc for this up the todo list.
> > >
> > > Without an approach like this certain sandboxes will fallback to
> > > ENOSYSing system calls they can't filter. This is a generic problem
> > > though with clone3() being one promiment example.
> >
> > Thank you for the detailed reply. It sounds to me like this will eventually have
> > to get solved anyway, so we could move ahead without clone() on loongarch,
> > and just not have support for Chrome until this is fully solved.
> >
> > As both the glibc and musl ports are being proposed for inclusion right
> > now, we should try to come to a decision so the libc ports can adjust if
> > necessary. Adding both mailing lists to Cc here, the discussion is archived
> > at [1].
> >
> >          Arnd
> >
> > [1] https://lore.kernel.org/linux-arch/20220509100058.vmrgn5fkk3ayt63v@wittgenstein/
>
> Having read about the seccomp issue, I think it's a very strong
> argument that __NR_clone should be kept permanently for all future
> archs.

Ok, let's keep clone() around for all architectures then. We should probably
just remove the __ARCH_WANT_SYS_CLONE macro and build the
code into the kernel unconditionally, but at the moment there
are still private versions for ia64 and sparc with the same name as
the generic version. Both are also still lacking support for clone3() and
don't have anyone actively working on them.

In this case, we probably don't need to change clone3() to allow the
zero-length stack after all, and the wrapper that was added to the
musl port should get removed again.

For the other syscalls, I think the latest musl patches already dropped
the old-style stat() implementation, but the glibc patches still have those
and need to drop them as well to match what the kernel will get.

       Arnd

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [musl] Re: [PATCH V9 13/24] LoongArch: Add system call support
  2022-05-12  7:21                 ` Arnd Bergmann
@ 2022-05-12 12:11                   ` Rich Felker
  0 siblings, 0 replies; 4+ messages in thread
From: Rich Felker @ 2022-05-12 12:11 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: musl, Christian Brauner, Huacai Chen, Huacai Chen,
	Andy Lutomirski, Thomas Gleixner, Peter Zijlstra, Andrew Morton,
	David Airlie, Jonathan Corbet, Linus Torvalds, linux-arch,
	open list:DOCUMENTATION, Linux Kernel Mailing List, Xuefeng Li,
	Yanteng Si, Guo Ren, Xuerui Wang, Jiaxun Yang, Linux API,
	GNU C Library

On Thu, May 12, 2022 at 09:21:13AM +0200, Arnd Bergmann wrote:
> On Wed, May 11, 2022 at 11:12 PM Rich Felker <dalias@libc.org> wrote:
> > On Wed, May 11, 2022 at 09:11:56AM +0200, Arnd Bergmann wrote:
> > > On Mon, May 9, 2022 at 12:00 PM Christian Brauner <brauner@kernel.org> wrote:
> > > .....
> > > > I can try and move a poc for this up the todo list.
> > > >
> > > > Without an approach like this certain sandboxes will fallback to
> > > > ENOSYSing system calls they can't filter. This is a generic problem
> > > > though with clone3() being one promiment example.
> > >
> > > Thank you for the detailed reply. It sounds to me like this will eventually have
> > > to get solved anyway, so we could move ahead without clone() on loongarch,
> > > and just not have support for Chrome until this is fully solved.
> > >
> > > As both the glibc and musl ports are being proposed for inclusion right
> > > now, we should try to come to a decision so the libc ports can adjust if
> > > necessary. Adding both mailing lists to Cc here, the discussion is archived
> > > at [1].
> > >
> > >          Arnd
> > >
> > > [1] https://lore.kernel.org/linux-arch/20220509100058.vmrgn5fkk3ayt63v@wittgenstein/
> >
> > Having read about the seccomp issue, I think it's a very strong
> > argument that __NR_clone should be kept permanently for all future
> > archs.
> 
> Ok, let's keep clone() around for all architectures then. We should probably
> just remove the __ARCH_WANT_SYS_CLONE macro and build the
> code into the kernel unconditionally, but at the moment there
> are still private versions for ia64 and sparc with the same name as
> the generic version. Both are also still lacking support for clone3() and
> don't have anyone actively working on them.
> 
> In this case, we probably don't need to change clone3() to allow the
> zero-length stack after all, and the wrapper that was added to the
> musl port should get removed again.

I still think disallowing a zero length (unknown length with caller
providing the start address only) stack is a gratuitous limitation on
the clone3 interface, and would welcome leaving the change to allow
zero-length in place. There does not seem to be any good justification
for forbidding it, and it does pose other real-world obstruction to
use. For example if your main thread had exited (or if you're forking
from a non-main thread) and you wanted to create a new process using
the old main thread stack as your stack, you would not know a
size/lowest-address, only a starting address from which it extends
some long (and possibly expanding) amount.

Rich

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-05-12 12:11 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20220430090518.3127980-1-chenhuacai@loongson.cn>
     [not found] ` <20220430090518.3127980-14-chenhuacai@loongson.cn>
     [not found]   ` <CAK8P3a0A9dW4mwJ6JHDiJxizL7vWfr4r4c5KhbjtAY0sWbZJVA@mail.gmail.com>
     [not found]     ` <CAAhV-H4te_+AS69viO4eBz=abBUm5oQ6AfoY1Cb+nOCZyyeMdA@mail.gmail.com>
     [not found]       ` <CAK8P3a0DqQcApv8aa2dgBS5At=tEkN7cnaskoUeXDi2-Bu9Rnw@mail.gmail.com>
     [not found]         ` <20220507121104.7soocpgoqkvwv3gc@wittgenstein>
     [not found]           ` <20220509100058.vmrgn5fkk3ayt63v@wittgenstein>
2022-05-11  7:11             ` [musl] Re: [PATCH V9 13/24] LoongArch: Add system call support Arnd Bergmann
2022-05-11 21:12               ` Rich Felker
2022-05-12  7:21                 ` Arnd Bergmann
2022-05-12 12:11                   ` Rich Felker

Code repositories for project(s) associated with this inbox:

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).