Hi James,
Please pull these seccomp changes for 3.17.
(And if I should base off something other than security-next, please
let me know. Or if there are any things I should be doing differently
with this tree.)
Thanks!
-Kees
The following changes since commit 32c2e6752ff0f48fe03b9e1c7c64bde580a840d2:
ima: provide double buffering for hash calculation (2014-07-17 09:35:11 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-3.17
for you to fetch changes up to c2e1f2e30daa551db3c670c0ccfeab20a540b9e1:
seccomp: implement SECCOMP_FILTER_FLAG_TSYNC (2014-07-18 12:13:40 -0700)
----------------------------------------------------------------
seccomp TSYNC support for 3.17
----------------------------------------------------------------
Kees Cook (12):
MAINTAINERS: create seccomp entry
seccomp: create internal mode-setting function
seccomp: extract check/assign mode helpers
seccomp: split mode setting routines
seccomp: add "seccomp" syscall
ARM: add seccomp syscall
MIPS: add seccomp syscall
sched: move no_new_privs into new atomic flags
seccomp: split filter prep from check and apply
seccomp: introduce writer locking
seccomp: allow mode setting across threads
seccomp: implement SECCOMP_FILTER_FLAG_TSYNC
MAINTAINERS | 10 +
arch/Kconfig | 1 +
arch/arm/include/uapi/asm/unistd.h | 1 +
arch/arm/kernel/calls.S | 1 +
arch/mips/include/uapi/asm/unistd.h | 15 +-
arch/mips/kernel/scall32-o32.S | 1 +
arch/mips/kernel/scall64-64.S | 1 +
arch/mips/kernel/scall64-n32.S | 1 +
arch/mips/kernel/scall64-o32.S | 1 +
arch/x86/syscalls/syscall_32.tbl | 1 +
arch/x86/syscalls/syscall_64.tbl | 1 +
fs/exec.c | 6 +-
include/linux/sched.h | 18 +-
include/linux/seccomp.h | 8 +-
include/linux/syscalls.h | 2 +
include/uapi/asm-generic/unistd.h | 4 +-
include/uapi/linux/seccomp.h | 7 +
kernel/fork.c | 49 ++++-
kernel/seccomp.c | 412 ++++++++++++++++++++++++++++++-----
kernel/sys.c | 4 +-
kernel/sys_ni.c | 3 +
security/apparmor/domain.c | 4 +-
22 files changed, 471 insertions(+), 80 deletions(-)
--
Kees Cook
Chrome OS Security
On Fri, 18 Jul 2014, Kees Cook wrote:
> Hi James,
>
> Please pull these seccomp changes for 3.17.
>
Pulled, thanks.
--
James Morris
<[email protected]>
On Fri, Jul 18, 2014 at 12:19:08PM -0700, Kees Cook wrote:
> Hi James,
>
> Please pull these seccomp changes for 3.17.
>
> (And if I should base off something other than security-next, please
> let me know. Or if there are any things I should be doing differently
> with this tree.)
One note; there is a (interim) syscall number collision with the new
getrandom(2) system call. I'm sure Linus will be able to handle it,
and fix it up, but I just wanted to give a heads up that depending on
which pull request hits mainline first, the syscall number for either
the new seccomp(2) or getrandom(2) may end up changing.
I've been warning people not to try to use getrandom(2) or check
anything into LibreSSL, et. al., until the patch is finalized and in
Linus's tree, but if you have userspace users already using the
syscall assignments in this patch series, please let me know and I can
try to make adjustments on my side.
Cheers,
- Ted
On Fri, Jul 18, 2014 at 11:16 PM, Theodore Ts'o <[email protected]> wrote:
> On Fri, Jul 18, 2014 at 12:19:08PM -0700, Kees Cook wrote:
>> Hi James,
>>
>> Please pull these seccomp changes for 3.17.
>>
>> (And if I should base off something other than security-next, please
>> let me know. Or if there are any things I should be doing differently
>> with this tree.)
>
> One note; there is a (interim) syscall number collision with the new
> getrandom(2) system call. I'm sure Linus will be able to handle it,
> and fix it up, but I just wanted to give a heads up that depending on
> which pull request hits mainline first, the syscall number for either
> the new seccomp(2) or getrandom(2) may end up changing.
>
> I've been warning people not to try to use getrandom(2) or check
> anything into LibreSSL, et. al., until the patch is finalized and in
> Linus's tree, but if you have userspace users already using the
> syscall assignments in this patch series, please let me know and I can
> try to make adjustments on my side.
No worries -- the only user of the seccomp syscall that I know of is
the seccomp regression testing suite, and that'd be trivially to fix.
I would note that the seccomp series includes adding the syscall also
to ARM and MIPS, so from a collision fixing perspective, it may be
fewer edits to fix getrandom instead. :)
-Kees
--
Kees Cook
Chrome OS Security
On Sat, Jul 19, 2014 at 07:49:55AM -0700, Kees Cook wrote:
>
> No worries -- the only user of the seccomp syscall that I know of is
> the seccomp regression testing suite, and that'd be trivially to fix.
>
> I would note that the seccomp series includes adding the syscall also
> to ARM and MIPS, so from a collision fixing perspective, it may be
> fewer edits to fix getrandom instead. :)
I've only wired up x86 and x86_64 for getrandom(2) so far. I had
assumed the ARM and MIPS folks would prefer to wire up new syscalls on
their own...
- Ted