On Mon, Aug 11, 2014 at 1:07 PM, Geert Uytterhoeven <ge...@linux-m68k.org> 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@vger.kernel.org> wrote: >> Gitweb: >> http://git.kernel.org/linus/;a=commit;h=48dc92b9fc3926844257316e75ba11eb5c742b2c >> Commit: 48dc92b9fc3926844257316e75ba11eb5c742b2c >> Parent: 3b23dd12846215eff4afb073366b80c0c4d7543e >> Refname: refs/heads/master >> Author: Kees Cook <keesc...@chromium.org> >> AuthorDate: Wed Jun 25 16:08:24 2014 -0700 >> Committer: Kees Cook <keesc...@chromium.org> >> 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 <keesc...@chromium.org> >> Reviewed-by: Oleg Nesterov <o...@redhat.com> >> Reviewed-by: Andy Lutomirski <l...@amacapital.net> > > 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-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
