Re: [Ksummit-discuss] [TECH TOPIC] seccomp feature development

Kees Cook <[email protected]> Wed, 20 May 2020 13:52:30 -0700
Newsgroups org.linuxfoundation.lists.ksummit-discuss,dev.linux.lists.ksummit
Message-ID <202005201340.ED17EDC@keescook>
On Wed, May 20, 2020 at 10:24:01PM +0200, Christian Brauner wrote:
> On Wed, May 20, 2020 at 12:08:52PM -0700, Linus Torvalds wrote:
> > On Wed, May 20, 2020 at 12:04 PM Kees Cook <[email protected]> wrote:
> > > Perhaps the question is "how deeply does seccomp need to inspect?"
> > > and maybe it does not get to see anything beyond just the "top level"
> > > struct (i.e. struct clone_args) and all pointers within THAT become
> > > opaque? That certainly simplifies the design.
> > 
> > Exactly. I think that's the most common situation by far. Does anybody
> > really really need to care at a deep level, and why?
> 
> We mostly don't and making all second-level pointers opaque is ok imho.

That'll make things MUCH easier. :)

> But I think that we need some documented consensus on all that stuff
> which I stressed in other mails before. I'll hand something in about
> this, if that's ok than we can hash this out.

Aleksa, I know you had an entire presentation[1] on the extensible
argument syscalls, but was there any text-based design doc that you made?

It would be really nice to update Documentation/process/adding-syscalls.rst
with the specifics[2], and to (now) include the "no nested flags"
requirement. What do you think?

-Kees

[1] https://github.com/cyphar/talks/tree/master/2020/01-linux-conf-au/syscall-extensions
    https://www.youtube.com/watch?v=ggD-eb3yPVs
[2] https://www.kernel.org/doc/html/latest/process/adding-syscalls.html?highlight=syscall#designing-the-api-planning-for-extension

-- 
Kees Cook
_______________________________________________
Ksummit-discuss mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss