Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3347511pxk; Mon, 21 Sep 2020 11:13:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy3VS67phbUv393TrW10BXKy/xYJS0CIdMXtrHWGfd/cAzP9tJ9kcWERFXVv57tlTdMR4D2 X-Received: by 2002:a50:fd19:: with SMTP id i25mr201168eds.142.1600711988225; Mon, 21 Sep 2020 11:13:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600711988; cv=none; d=google.com; s=arc-20160816; b=hzMIlqBip7ctmXgBJDqqaJzl9qu18q3Sb3AFZ+B1kmUNl2GAdXvfAcFdc0lZoL4v2u r8tVHK4QPI414mHnECQKSU714uahaq1zWrY6l5i/qgSery04UUsiXfTMkR1KkLRWsLsz b19ib7uZuz9aX9Wrl4OoZu94XhCRPNZU6JlZ+zc6xxeG0w3PDp6T7/JDQYOpxMWi1vjT llKkutmINXHSqgRdXl9cn39+65HAnhCgPGkSG+3kzynC6jxLQy295lFNUqUghcr6FQ4O YOH6c8FqgrKwSu/MBQ4j3VPr79HEi+bZTZlv49XzUcnoWW0++sKGp2t6XvRwL8eD0j03 1/5w== 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=U2gRVRvTDWwfATk5t7wFIm55wjeGEEthD9jAmx8WrwQ=; b=nlRvvzYlaQntzfNi9id1fOeNJVpyafP+4HJ1EXuQcVRMpL34ZWeJlzUZFwte3sxOvl QlpAKom8XtBtEE3u/RNwUHmLLP+iH48y/P0vSMwa4y0dQzspHDHRjXLYg80+7/YSByrf r1xREwgp4fME9uk2sKd8IHbnZTBjhL2KETcy7I6O3dNxu0y+EBOIjPX58mG6YyfZF2pO Tg5szJ6VASWxnA11cdAebVjg0/I4S2972EJewYMbSSx4eHFAFEHEdXBAfpgImcW4Riyz +5MpgnWYuOkVYY9ydVCJhe0ordyb6c7gdo6gQWA+AtmVDRaGyTBumT1QzSEuGL2HUYQa y//w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=V2T3MJ1W; 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 a13si6283982edt.450.2020.09.21.11.12.45; Mon, 21 Sep 2020 11:13:08 -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=V2T3MJ1W; 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 S1727987AbgIUSJX (ORCPT + 99 others); Mon, 21 Sep 2020 14:09:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47290 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726436AbgIUSJW (ORCPT ); Mon, 21 Sep 2020 14:09:22 -0400 Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6FB41C061755 for ; Mon, 21 Sep 2020 11:09:22 -0700 (PDT) Received: by mail-ed1-x541.google.com with SMTP id j2so13709342eds.9 for ; Mon, 21 Sep 2020 11:09:22 -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=U2gRVRvTDWwfATk5t7wFIm55wjeGEEthD9jAmx8WrwQ=; b=V2T3MJ1WcOFZii4NxoAWnxNlQBSG9qyAOklIbpUH+vhVdFe3M9VI02LT3Cvam9WpPI UuT21fUhJvYgQPyLacXu9q5TrAknbhiJ6cmqm0QDdwSNyU1saUwJf45JRhkBwG6/kknw eFi97FQTDbWXRtlGpvqo5R1PcAdBSFObnBCFBfxZchUMz3Wm/rAlQcQXukGXh02ZkdQR Tjx5XwLp5sFAEwJjpAbIssiDdnrUMhvgsKzYKfXV07QmVxc7nUNWEwzX7Ut+2Tb6m3Dh ejZs+LcYMZLrVAyupT44BI22vllUq2EpmffRZO2ZrPRMzVLGpLLNMwqw+dqFNdTwe2fx oS2Q== 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=U2gRVRvTDWwfATk5t7wFIm55wjeGEEthD9jAmx8WrwQ=; b=eH5QO8S7x8iTbdiOMRrZm+altnMzSB7rN9p0Lhqn5nNSpgUYOC0bdTCGeBCxsP9QVN uXGCCQ67GBe/A1DSDWKzs40OiHrPmc4OCMboKRxs9MftNgXbUHJFtG+p98U7ZJDBZMbq i/dB5jyY3ED9Uc31vzcNQ7cjOAiPvGAbnrB0N2orB/hDZkfNx4t/fU83vDveQWTEL8Ze yKFo443VvHTXOb8zoVtkrhNBt917EGTdsrDpPjUSivO/6olqGgeE4kqVp0lDHXX4Mxis RCcJpS5VflWlJEWZMbQueDDn5GE/w2WIOimdmFv4I+h7O5lKGWo1o4EXjabk6XPq488F iXbA== X-Gm-Message-State: AOAM532RVSAphyUVEgNcDzAQezwtnSY2V5O3IsTJOtHSFYv12UrkEYGO ajFmJcMJLYHOmsrKkrFsPk+s8wkWKf+cQ60NSFYLNg== X-Received: by 2002:a05:6402:cba:: with SMTP id cn26mr173873edb.230.1600711760904; Mon, 21 Sep 2020 11:09:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jann Horn Date: Mon, 21 Sep 2020 20:08:54 +0200 Message-ID: Subject: Re: [RFC PATCH seccomp 2/2] seccomp/cache: Cache filter results that allow syscalls To: YiFei Zhu Cc: Linux Containers , YiFei Zhu , bpf , Andrea Arcangeli , Dimitrios Skarlatos , Giuseppe Scrivano , Hubertus Franke , Jack Chen , Josep Torrellas , Kees Cook , Tianyin Xu , Tobin Feldman-Fitzthum , Valentin Rothberg , Andy Lutomirski , Will Drewry , Aleksa Sarai , kernel list Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 21, 2020 at 7:35 AM YiFei Zhu wrote: [...] > We do this by creating a per-task bitmap of permitted syscalls. > If seccomp filter is invoked we check if it is cached and if so > directly return allow. Else we call into the cBPF filter, and if > the result is an allow then we cache the results. What? Why? We already have code to statically evaluate the filter for all syscall numbers. We should be using the results of that instead of re-running the filter and separately caching the results. > The cache is per-task Please don't. The static results are per-filter, so the bitmask(s) should also be per-filter and immutable. > minimize thread-synchronization issues in > the hot path of cache lookup There should be no need for synchronization because those bitmasks should be immutable. > and to avoid different architecture > numbers sharing the same cache. There should be separate caches for separate architectures, and we should precompute the results for all architectures. (We only have around 2 different architectures max, so it's completely reasonable to precompute and store all that.) > To account for one thread changing the filter for another thread of > the same process, the per-task struct also contains a pointer to > the filter the cache is built on. When the cache lookup uses a > different filter then the last lookup, the per-task cache bitmap is > cleared. Unnecessary complexity, we don't need that if we make the bitmasks immutable.