Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965125AbaFCXrx (ORCPT ); Tue, 3 Jun 2014 19:47:53 -0400 Received: from mail-vc0-f179.google.com ([209.85.220.179]:44466 "EHLO mail-vc0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932164AbaFCXrv (ORCPT ); Tue, 3 Jun 2014 19:47:51 -0400 MIME-Version: 1.0 In-Reply-To: References: <1400799936-26499-1-git-send-email-keescook@chromium.org> Date: Tue, 3 Jun 2014 16:47:50 -0700 Message-ID: Subject: Re: [PATCH v5 0/6] seccomp: add PR_SECCOMP_EXT and SECCOMP_EXT_ACT_TSYNC From: Julien Tinnes To: Michael Kerrisk Cc: Andy Lutomirski , Kees Cook , Linux API , Andrew Morton , Oleg Nesterov , James Morris , Stephen Rothwell , "David S. Miller" , LKML , Will Drewry , 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 Tue, Jun 3, 2014 at 3:12 AM, Michael Kerrisk wrote: > [Kees, thank you for CCing linux-api] > > On Tue, Jun 3, 2014 at 1:08 AM, Andy Lutomirski wrote: >> On Mon, Jun 2, 2014 at 4:05 PM, Kees Cook wrote: > >>> I'd like to hear from other folks on this (akpm?). My instinct is to >>> continue using prctl since that is already where mediation for seccomp >>> happens. I don't see why prctl vs a new syscall makes a difference >>> here, frankly. >> >> Aesthetics? There's a tendency for people to get annoyed at big >> multiplexed APIs, and your patches will be doubly multiplexed. > > prctl() is already a Franken-interface that provides a mass of > different, mostly completely unrelated, functionality. So, I wonder if > it would be better not to make the situation worse. Furthermore, the > very fact that the existing prctl seccomp API is being extended and > multiplexed suggests that other extensions might be desirable further > down the line, which also hints that a separate syscall would be a > good idea. (Or do we have to wait until the prctl seccomp API is > extended one more time, before we realize that a new system call would > have been a good idea...) > >> TBH, I care more about the atomicity thing than about the actual form >> of the API. > > User-space does not necessarily thank you for that perspective, Andy > ;-). The atomicity thing is presumably fixable, regardless of the API. > On the other hand, APIs are things that kernel developers design once > and forget about, and user-space has to live with forever. Well, maybe the history of it being a prctl() should count for something. Most likely, userland will need to test for whether or not these features are present in the kernel for years to come. With a syscall, it would now require a syscall (unlikely to be in older headers for a while, so will require using syscall(3) for a bit) as well as a call to prctl() to test for seccomp mode 2 (without thread sync) in the fallback path. It'll be a little odd. As the person who will make this work in Chromium, I do not feel strongly either way, it's a detail, so feel free to disregard this point. But I'm eagerly waiting for: - Not having to test for the presence of threads at run-time (which requires a very ugly busy loop with exponential back-off watching for /proc/self/tasks/ to drop to 1 directory entry). - Being able to engage the sandbox after third-party libraries have started threads. Julien -- 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/