Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756747AbaGVThs (ORCPT ); Tue, 22 Jul 2014 15:37:48 -0400 Received: from mail-oi0-f46.google.com ([209.85.218.46]:59661 "EHLO mail-oi0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752641AbaGVThq (ORCPT ); Tue, 22 Jul 2014 15:37:46 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 22 Jul 2014 12:37:45 -0700 X-Google-Sender-Auth: fNCVl91x2h1xy1SJ8D7LTfe-r70 Message-ID: Subject: Re: [PATCH v3 0/8] Two-phase seccomp and x86 tracing changes From: Kees Cook To: Andy Lutomirski , "H. Peter Anvin" Cc: LKML , Will Drewry , Oleg Nesterov , "x86@kernel.org" , "linux-arm-kernel@lists.infradead.org" , Linux MIPS Mailing List , linux-arch , linux-security-module , Alexei Starovoitov Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 21, 2014 at 6:49 PM, Andy Lutomirski wrote: > [applies on jmorris's security-next tree] > > This is both a cleanup and a speedup. It reduces overhead due to > installing a trivial seccomp filter by 87%. The speedup comes from > avoiding the full syscall tracing mechanism for filters that don't > return SECCOMP_RET_TRACE. > > This series works by splitting the seccomp hooks into two phases. > The first phase evaluates the filter; it can skip syscalls, allow > them, kill the calling task, or pass a u32 to the second phase. The > second phase requires a full tracing context, and it sends ptrace > events if necessary. > > Once this is done, I implemented a similar split for the x86 syscall > entry work. The C callback is invoked in two phases: the first has > only a partial frame, and it can request phase 2 processing with a > full frame. > > Finally, I switch the 64-bit system_call code to use the new split > entry work. This is a net deletion of assembly code: it replaces > all of the audit entry muck. > > In the process, I fixed some bugs. > > If this is acceptable, someone can do the same tweak for the > ia32entry and entry_32 code. > > This passes all seccomp tests that I know of. Now that it's properly > rebased, even the previously expected failures are gone. > > Kees, if you like this version, can you create a branch with patches > 1-4? I think that the rest should go into tip/x86 once everyone's happy > with it. > > Changes from v2: > - Fixed 32-bit x86 build (and the tests pass). > - Put the doc patch where it belongs. Thanks! This looks good to me. I'll add it to my tree. Peter, how do you feel about this series? Do the x86 changes look good to you? -Kees > > Changes from v1: > - Rebased on top of Kees' shiny new seccomp tree (no effect on the x86 > part). > - Improved patch 6 vs patch 7 split (thanks Alexei!) > - Fixed bogus -ENOSYS in patch 5 (thanks Kees!) > - Improved changelog message in patch 6. > > Changes from RFC version: > - The first three patches are more or less the same > - The rest is more or less a rewrite > > Andy Lutomirski (8): > seccomp,x86,arm,mips,s390: Remove nr parameter from secure_computing > seccomp: Refactor the filter callback and the API > seccomp: Allow arch code to provide seccomp_data > seccomp: Document two-phase seccomp and arch-provided seccomp_data > x86,x32,audit: Fix x32's AUDIT_ARCH wrt audit > x86: Split syscall_trace_enter into two phases > x86_64,entry: Treat regs->ax the same in fastpath and slowpath > syscalls > x86_64,entry: Use split-phase syscall_trace_enter for 64-bit syscalls > > arch/Kconfig | 11 ++ > arch/arm/kernel/ptrace.c | 7 +- > arch/mips/kernel/ptrace.c | 2 +- > arch/s390/kernel/ptrace.c | 2 +- > arch/x86/include/asm/calling.h | 6 +- > arch/x86/include/asm/ptrace.h | 5 + > arch/x86/kernel/entry_64.S | 51 ++++----- > arch/x86/kernel/ptrace.c | 150 +++++++++++++++++++----- > arch/x86/kernel/vsyscall_64.c | 2 +- > include/linux/seccomp.h | 25 ++-- > kernel/seccomp.c | 252 ++++++++++++++++++++++++++++------------- > 11 files changed, 360 insertions(+), 153 deletions(-) > > -- > 1.9.3 > -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/