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