[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG48ez2wyDhM-V1hs5ya1R4x7wHT=T8XLOYCPUyw97kzzLhbhg@mail.gmail.com>
Date: Mon, 27 May 2019 21:36:18 +0200
From: Jann Horn <jannh@...gle.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
Kees Cook <keescook@...omium.org>,
Christian Brauner <christian@...uner.io>
Cc: Al Viro <viro@...iv.linux.org.uk>,
Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
Florian Weimer <fweimer@...hat.com>,
Oleg Nesterov <oleg@...hat.com>, Arnd Bergmann <arnd@...db.de>,
David Howells <dhowells@...hat.com>,
Pavel Emelyanov <xemul@...tuozzo.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Adrian Reber <adrian@...as.de>,
Andrei Vagin <avagin@...il.com>,
Linux API <linux-api@...r.kernel.org>
Subject: Re: [PATCH 1/2] fork: add clone6
+Kees
On Mon, May 27, 2019 at 9:27 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Mon, May 27, 2019 at 3:42 AM Christian Brauner <christian@...uner.io> wrote:
> > Hm, still pondering whether having one unsigned int argument passed
> > through registers that captures all the flags from the old clone() would
> > be a good idea.
>
> That sounds like a reasonable thing to do.
>
> Maybe we could continue to call the old flags CLONE_XYZ and continue
> to pass them in as "flags" argument, and then we have CLONE_EXT_XYZ
> flags for a new 64-bit flag field that comes in through memory in the
> new clone_args thing?
With the current seccomp model, that would have the unfortunate effect
of making it impossible to filter out new clone flags - which would
likely mean that people who want to sandbox their code would not use
the new clone() because they don't want their sandboxed code to be
able to create time namespaces and whatever other new fancy things
clone() might support in the future. This is why I convinced Christian
to pass flags in registers for the first patch version.
The alternative I see would be to somehow extend seccomp to support
argument structures that are passed in memory - that would probably
require quite a bit of new plumbing though, both in the kernel and in
userspace code that configures seccomp filters.
Powered by blists - more mailing lists