lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 11 Aug 2014 22:07:12 +0200
From:	Geert Uytterhoeven <>
To:	Kees Cook <>
Cc:	Linux-Arch <>,
	"" <>
Subject: Re: seccomp: add "seccomp" syscall

Hi Kees,

v3.17 is gonna get a lot of new syscalls...

On Wed, Aug 6, 2014 at 6:27 PM, Linux Kernel Mailing List
<> wrote:
> Gitweb:;a=commit;h=48dc92b9fc3926844257316e75ba11eb5c742b2c
> Commit:     48dc92b9fc3926844257316e75ba11eb5c742b2c
> Parent:     3b23dd12846215eff4afb073366b80c0c4d7543e
> Refname:    refs/heads/master
> Author:     Kees Cook <>
> AuthorDate: Wed Jun 25 16:08:24 2014 -0700
> Committer:  Kees Cook <>
> 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 <>
>     Reviewed-by: Oleg Nesterov <>
>     Reviewed-by: Andy Lutomirski <>

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?




Geert Uytterhoeven -- There's lots of Linux beyond ia32 --

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists