On Mon, Aug 11, 2014 at 1:07 PM, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > Hi Kees, > > v3.17 is gonna get a lot of new syscalls... 4 so far! :P > > On Wed, Aug 6, 2014 at 6:27 PM, Linux Kernel Mailing List > <linux-kernel@xxxxxxxxxxxxxxx> wrote: >> Gitweb: http://git.kernel.org/linus/;a=commit;h=48dc92b9fc3926844257316e75ba11eb5c742b2c >> Commit: 48dc92b9fc3926844257316e75ba11eb5c742b2c >> Parent: 3b23dd12846215eff4afb073366b80c0c4d7543e >> Refname: refs/heads/master >> Author: Kees Cook <keescook@xxxxxxxxxxxx> >> AuthorDate: Wed Jun 25 16:08:24 2014 -0700 >> Committer: Kees Cook <keescook@xxxxxxxxxxxx> >> CommitDate: Fri Jul 18 12:13:37 2014 -0700 >> >> seccomp: add "seccomp" syscall >> >> This adds the new "seccomp" syscall with both an "operation" and "flags" >> parameter for future expansion. The third argument is a pointer value, >> used with the SECCOMP_SET_MODE_FILTER operation. Currently, flags must >> be 0. This is functionally equivalent to prctl(PR_SET_SECCOMP, ...). >> >> In addition to the TSYNC flag later in this patch series, there is a >> non-zero chance that this syscall could be used for configuring a fixed >> argument area for seccomp-tracer-aware processes to pass syscall arguments >> in the future. Hence, the use of "seccomp" not simply "seccomp_add_filter" >> for this syscall. Additionally, this syscall uses operation, flags, >> and user pointer for arguments because strictly passing arguments via >> a user pointer would mean seccomp itself would be unable to trivially >> filter the seccomp syscall itself. >> >> Signed-off-by: Kees Cook <keescook@xxxxxxxxxxxx> >> Reviewed-by: Oleg Nesterov <oleg@xxxxxxxxxx> >> Reviewed-by: Andy Lutomirski <luto@xxxxxxxxxxxxxx> > > Is this something that I should enable? > > As it depends on CONFIG_SECCOMP, it only makes sense on architectures that > already support CONFIG_SECCOMP, right? > Does it make sense to reserve a syscall slot for it on architectures that > don't support it yet? I don't see a good reason to reserve the syscall slot if seccomp filter is not already implemented. I've CCed linux-api in case there is something I'm not considering, though. FWIW, if someone wants to add it for m68k, the steps to support seccomp are listed in the arch/Kconfig for HAVE_ARCH_SECCOMP_FILTER. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
