From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757145AbbFQSNN (ORCPT ); Wed, 17 Jun 2015 14:13:13 -0400 Received: from mail-yk0-f170.google.com ([209.85.160.170]:35722 "EHLO mail-yk0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752966AbbFQSM6 (ORCPT ); Wed, 17 Jun 2015 14:12:58 -0400 MIME-Version: 1.0 In-Reply-To: <1434526286.28933.2.camel@ellerman.id.au> References: <20150616175414.GA24958@www.outflux.net> <1434526286.28933.2.camel@ellerman.id.au> Date: Wed, 17 Jun 2015 11:12:56 -0700 X-Google-Sender-Auth: zxLVQVoHkotbGbfqaUBb5rxr0hE Message-ID: Subject: Re: [PATCH] selftests: add seccomp suite From: Kees Cook To: Michael Ellerman Cc: LKML , Daniel Borkmann , Shuah Khan , Andy Lutomirski , Will Drewry , Andrew Morton , Greg KH , Mauro Carvalho Chehab , "David S. Miller" , Arnd Bergmann , Joe Perches , Jingoo Han , Linux API 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 Wed, Jun 17, 2015 at 12:31 AM, Michael Ellerman wrote: > On Tue, 2015-06-16 at 10:54 -0700, Kees Cook wrote: >> This imports the existing seccomp test suite into the kernel's selftests >> tree. It contains extensive testing of seccomp features and corner cases. >> There remain additional tests to move into the kernel tree, but they have >> not yet been ported to all the architectures seccomp supports: >> https://github.com/redpig/seccomp/tree/master/tests >> >> Signed-off-by: Kees Cook >> --- >> MAINTAINERS | 1 + >> tools/testing/selftests/Makefile | 1 + >> tools/testing/selftests/seccomp/.gitignore | 1 + >> tools/testing/selftests/seccomp/Makefile | 10 + >> tools/testing/selftests/seccomp/seccomp_bpf.c | 2109 ++++++++++++++++++++++++ >> tools/testing/selftests/seccomp/test_harness.h | 537 ++++++ > > > Thanks very much for adding this, it would have been very helpful recently when > I was trying to get seccomp filter working on powerpc :) > > I get one failure in TRACE_syscall.syscall_dropped: > > seccomp_bpf.c:1394:TRACE_syscall.syscall_dropped:Expected 1 (1) == syscall(207) (18446744073709551615) > > > So it looks like we're returning -1 instead of 1. > > That's probably a bug in our handling of the return value, or maybe an > inconsistency across the arches. I'll try and find time to dig into it. Ah-ha! Excellent. Did you add an implementation for change_syscall() in seccomp_bpf.c? I don't have a powerpc method in there. I would have expected both TRACE_syscall.syscall_redirected and .syscall_dropped to fail without that. If you did, maybe something isn't right with regs.SYSCALL_RET ? That's where the return value being tested on a skipped syscall is stored. Thanks for testing! -Kees -- Kees Cook Chrome OS Security