Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933319Ab1D1P6E (ORCPT ); Thu, 28 Apr 2011 11:58:04 -0400 Received: from mail-vw0-f46.google.com ([209.85.212.46]:57683 "EHLO mail-vw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933307Ab1D1P57 (ORCPT ); Thu, 28 Apr 2011 11:57:59 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=VvvUcVVzDPt2tt2Kgg2mwbjhxwIbbRY+JNC1AfWnFUFlTiJ1tLthzIWggDsUID8MuD 4+0+D7400Xo2YopboYh4urHanPzPRo4dSr5i9q9AVsn9U5tS6r0mJ2ILavZJJA0wgQis bDbaMpTALnKcabfPERT3p4EoM+SAzh+2YJ9EM= Date: Thu, 28 Apr 2011 17:57:48 +0200 From: Frederic Weisbecker To: Will Drewry Cc: linux-kernel@vger.kernel.org, kees.cook@canonical.com, eparis@redhat.com, agl@chromium.org, mingo@elte.hu, jmorris@namei.org, rostedt@goodmis.org, Ingo Molnar , Andrew Morton , Tejun Heo , Michal Marek , Oleg Nesterov , Roland McGrath , Peter Zijlstra , Jiri Slaby , David Howells , "Serge E. Hallyn" Subject: Re: [PATCH 3/7] seccomp_filter: Enable ftrace-based system call filtering Message-ID: <20110428155745.GF1798@nowhere> References: <1303960136-14298-1-git-send-email-wad@chromium.org> <1303960136-14298-2-git-send-email-wad@chromium.org> <20110428142857.GC1798@nowhere> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2752 Lines: 51 On Thu, Apr 28, 2011 at 10:15:04AM -0500, Will Drewry wrote: > On Thu, Apr 28, 2011 at 9:29 AM, Frederic Weisbecker wrote: > > On Wed, Apr 27, 2011 at 10:08:47PM -0500, Will Drewry wrote: > >> This change adds a new seccomp mode based on the work by > >> agl@chromium.org. This mode comes with a bitmask of NR_syscalls size and > >> an optional linked list of seccomp_filter objects. When in mode 2, all > > > > Since you now use the filters. Why not using them to filter syscalls > > entirely rather than using a bitmap of allowed syscalls? > > The current approach just uses a linked list of filters. While a more > efficient data structure could be used, the bitmask provides a quick > binary decision, and optimizes for the relatively common case where > there won't be many non-binary filters to evaluate so we don't have to > walk the list for a larger number of yes/no decisions versus more > complex predicates. Though that may be a short-sighted view! I'm > happy to change it up. Well, using a hlist that points to the filters may be not that slower. Dunno, that needs to be measured perhaps. No big deal for now. > > > You have the "nr" field in syscall tracepoints. > > I'n not sure I follow. Do you mean moving entirely to using the > actual tracepoint infrastructure instead of using the seccomp hooks, > or just looking up proper filter by syscall nr? If there's a sane and > better way to do the latter, I'm all ears :) As far as using the > tracepoints themselves, I looked to how the perf/ftrace interactions > worked and while I could've registered with the syscalls tracepoints > for enter and exit, it would mean later evaluation of the system call > interception, possibly out-of-order with respect to other registered > event sinks, and there is complexity in just killing current from > within the notifier-like list registered syscall events (as Eric Paris > ran into when expanding filtering into perf itself). To get around > that, the tracepoint handler would have to pump the data somewhere > else (like it does for perf), and it just seemed messy. I think it's > doable, but I don't know that the pure syscall tracepoint > infrastructure should be burdened with the added requirements that > come with seccomp-filtering. If I didn't properly understand the > code, though, please set me on the right path. No, my bad I was confused. I always post questions that show my misunderstanding of a new (or not) patchset. It's like a tradition ;) -- 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/