Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp290279pxk; Thu, 24 Sep 2020 05:58:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy34lHQgQLTcJBSxo6SR+ERn8sFLhdGI/6EJT7PjFMKRIPdHLN+X87SAPPreoxH9N40O7nS X-Received: by 2002:a50:f287:: with SMTP id f7mr926737edm.158.1600952333594; Thu, 24 Sep 2020 05:58:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600952333; cv=none; d=google.com; s=arc-20160816; b=H15W/Eb+crIvUHMX/ZCags2R2/e2lGINMUGu8v7kcDGVUi/4SJ9GciYf1P328D2/SY /ovZaTblygn4aEM6LBT5n+3jn/mknH/F6z0x69r1Xer6jsleuCIU+YZc5JqHXZe5KwYG jIsKJqqhTlcf+XGFKX7+kmKl9+dYox2SZOJzJ0ax/QyBnoLuJMsK2Bq8HroJw11GT21b BWFJp8dhnGYP6I7EDpYZktdsrLLmivuu3f3HtUFMxoIvaLt6MPq5bZcL2JUt06cbQfz3 l2f6QkMv9HCxTk62t8YH3hesrcDftozkm2dspaOzPexq4dYizU566JCr0A8atrDalaX5 Y+gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=6PIyzkE03cr+kvJe1Aijo1Xyt0QaH2RNf7w1MklGRBQ=; b=HSuBk4DgxTkLTWOfSvXJiZ4azqe2y88BP8k4XtOQMKoB8j7w8SDBd4L4ljFIeLyzYW fLJNA6h6/FQfE3mIjlzjkYNssZ6fAPu7xLrwX8bi9CNtIyb1xlgmy4xDW9JRpj+V6a1U pw+clIqfwijJsk5x4eANaEzLQCBi0mr7tlpQYzYhkXH64d9F3LgQKGATTz4qE5Nevo7n cy3ufj1oWj0n+x7G0fQTvMi/75+ew+VFaLhXMYuQOUztCL4JkYioDFO2sy2FlYzvPLxd 240gvdN3lY730kuV5rrWYOSGPg/Mgpxi5TSrqGRpGQfLYHPyt1RyXWR/dKbCn9usglXd 0asw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=kJB1nGYx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b7si2105025edr.520.2020.09.24.05.58.29; Thu, 24 Sep 2020 05:58:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=kJB1nGYx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727800AbgIXM4s (ORCPT + 99 others); Thu, 24 Sep 2020 08:56:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43582 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727798AbgIXM4r (ORCPT ); Thu, 24 Sep 2020 08:56:47 -0400 Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com [IPv6:2a00:1450:4864:20::543]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9ADEEC0613D3 for ; Thu, 24 Sep 2020 05:56:47 -0700 (PDT) Received: by mail-ed1-x543.google.com with SMTP id l17so3204631edq.12 for ; Thu, 24 Sep 2020 05:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6PIyzkE03cr+kvJe1Aijo1Xyt0QaH2RNf7w1MklGRBQ=; b=kJB1nGYxP0Y6X5WheYqJQFpCi5sL6A711gpSeHDvuzgkectzUE/MXMOOEAnyElFD9v iqJyfIN/NSmWXrpVuFZ0aho0aDIFIpkMOw1pyuVo0+VxTny2vbcrMcsb9bSkOD2pXiG3 Dvl8rC/5qu8B0ATDNukQW590sTpDnKOF0N0ECVTvm6I8NaeU/cOkLhrQclT3Uw6+H6sk /qht2lFhpsGuqbERJ1ekX/lZmTpUh5+Dak+m/8EL3mc+x8jKSLvoDXJXDjOHzU8GK7vZ udXjSph+fxFzM8V094eG/lbsSo3u9cohPOEWwxr8UoH1Ss++gokbpNmfxCbBkzFK3vEe Rtuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6PIyzkE03cr+kvJe1Aijo1Xyt0QaH2RNf7w1MklGRBQ=; b=mvWjqTWSolCdceSXbFxzz83a5SAFNzQGT4Qe2FlqDLfuG7v9IHP0UKCsJsrl9Rj8kw 2uRZzKRrUUtQra1IBK8AxZ/fUKWZDO4ZE/0AP8spyQ1IEq3pPw9gnFivzkVgnRwX+zGZ U20fi1+HlXE2DZWGn1Wk4m3XZ74og/2b7/zAPG+PAdjg5EbOA3puaF7+6yU52tpQMocS o8+sD5EpWoKvSpjsmVkszVY/7ve2SqurqCeJBm3HcAC58UhpBXSy7K5zsqHDSwNE/Ai+ kKt5awLiehK1kEBq6y1qZykdfUK+V/92EoMxgm8ggmVBm+d/YdfiJKE/le/B3FyAGffb snTw== X-Gm-Message-State: AOAM531zYcXaqnYLXm/31X1Kx18zbVLyWnrxt3/+5H4rm7F2RuDwymM+ SRYQYxtohpB2bOoxma7AmmkWfazrdyDBTDYkovqv1Q== X-Received: by 2002:a50:ccd2:: with SMTP id b18mr885315edj.51.1600952205967; Thu, 24 Sep 2020 05:56:45 -0700 (PDT) MIME-Version: 1.0 References: <20200923232923.3142503-1-keescook@chromium.org> <20200923232923.3142503-4-keescook@chromium.org> <202009240018.A4D8274F@keescook> In-Reply-To: From: Jann Horn Date: Thu, 24 Sep 2020 14:56:19 +0200 Message-ID: Subject: Re: [PATCH 3/6] seccomp: Implement constant action bitmaps To: David Laight Cc: Kees Cook , YiFei Zhu , Christian Brauner , Tycho Andersen , Andy Lutomirski , Will Drewry , Andrea Arcangeli , Giuseppe Scrivano , Tobin Feldman-Fitzthum , Dimitrios Skarlatos , Valentin Rothberg , Hubertus Franke , Jack Chen , Josep Torrellas , Tianyin Xu , bpf , Linux Containers , Linux API , kernel list Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 24, 2020 at 2:37 PM David Laight wrote: > From: Jann Horn > > Sent: 24 September 2020 13:29 > ... > > I think our goal here should be that if a syscall is always allowed, > > seccomp should execute the smallest amount of instructions we can get > > away with, and touch the smallest amount of memory possible (and > > preferably that memory should be shared between threads). The bitmap > > fastpath should probably also avoid populate_seccomp_data(). > > If most syscalls are expected to be allowed E.g. OpenSSH's privilege-separated network process only permits something like 26 specific syscalls. > then an initial: > if (global_mask & (1u << (syscall_number & 63)) > test can be used to skip any further lookups. I guess that would work in principle, but I'm not convinced that it's worth adding another layer of global caching just to avoid one load instruction for locating the correct bitmask from the current process. Especially when it only really provides a benefit when people use seccomp improperly - for application sandboxing, you're supposed to only permit a list of specific syscalls, the smaller the better. > Although ISTR someone suggesting that the global_mask should > be per-cpu because even shared read-only cache lines were > expensive on some architecture. If an architecture did make that expensive, I think we have bigger problems to worry about than a little bitmap in seccomp. (Like the system call table.) So I think we don't have to worry about that here.