Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756054Ab2BQB0D (ORCPT ); Thu, 16 Feb 2012 20:26:03 -0500 Received: from smarthost1.greenhost.nl ([195.190.28.78]:54230 "EHLO smarthost1.greenhost.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755033Ab2BQB0A (ORCPT ); Thu, 16 Feb 2012 20:26:00 -0500 Message-ID: In-Reply-To: References: <1329422549-16407-1-git-send-email-wad@chromium.org> <1329422549-16407-3-git-send-email-wad@chromium.org> <4F3D61CB.2000301@zytor.com> <4F3D7250.6040504@zytor.com> <501858544d264abc6526f2b25a224f2b.squirrel@webmail.greenhost.nl> Date: Fri, 17 Feb 2012 02:25:55 +0100 Subject: Re: [PATCH v8 3/8] seccomp: add system call filtering using BPF From: "Indan Zupancic" To: "Andrew Lutomirski" Cc: "H. Peter Anvin" , "Will Drewry" , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, kernel-hardening@lists.openwall.com, netdev@vger.kernel.org, x86@kernel.org, arnd@arndb.de, davem@davemloft.net, mingo@redhat.com, oleg@redhat.com, peterz@infradead.org, rdunlap@xenotime.net, mcgrathr@chromium.org, tglx@linutronix.de, eparis@redhat.com, serge.hallyn@canonical.com, djm@mindrot.org, scarybeasts@gmail.com, pmoore@redhat.com, akpm@linux-foundation.org, corbet@lwn.net, eric.dumazet@gmail.com, markus@chromium.org, keescook@chromium.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.1 X-Scan-Signature: 5a1627636b35b65657045ef62631cd80 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1734 Lines: 40 On Fri, February 17, 2012 01:51, Andrew Lutomirski wrote: > IMO the best solution is to have the One True Seccomp Filter Compiler > (tm). It would handle multiple namespaces, cross-arch differences, > and such, and it would do it correctly. It could live in the kernel > tree. I'm not interested in any such compiler, if I use this BPF thing I'll use it directly by scanning my syscall table info and converting it to a BPF filter for the cases where it's possible. This code will be cross-platform, all the platform dependent info comes from the syscall table. It seems I'll just build a bitmask telling what to do for each syscall, with special cases for the few syscalls that can be handled totally within BPF by checking the arguments. My total lines of code is 5k now, I'm not going to use a complex thousands of lines, badly tested, probably buggy compiler just for BPF support. > Without something like that or an incredible amount of special care, > actual portability is probably a pipe dream. The filter programs are already platform dependent because of the syscall numbers and sometimes args differences. But that is no reason to make it even less cross-platform. Your OTSF compiler won't be able to handle different modes other than adding a check at the start and having totally orthogonal codes for the different cases. You can as well have separate filters then. Any other approach dies because of the added complexity or will be a lot slower. Greetings, Indan -- 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/