From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 31545C4363D for ; Mon, 21 Sep 2020 18:09:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DEA1D206FB for ; Mon, 21 Sep 2020 18:09:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="V2T3MJ1W" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728007AbgIUSJX (ORCPT ); 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-Google-Smtp-Source: ABdhPJxzS1PvJpZ0m2Z/pTgp6nyi4eUGvBkhh/prcxCQ3x14BnnFzuu2H8xHujssxKMeV+RGxPHlRe66XeYpkaMAD90= 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.