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=-5.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 BF0DAC4727E for ; Fri, 25 Sep 2020 20:35:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 77B79206D4 for ; Fri, 25 Sep 2020 20:35:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="dtRToJmy" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728794AbgIYUdQ (ORCPT ); Fri, 25 Sep 2020 16:33:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51832 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727151AbgIYUUM (ORCPT ); Fri, 25 Sep 2020 16:20:12 -0400 Received: from mail-pj1-x1042.google.com (mail-pj1-x1042.google.com [IPv6:2607:f8b0:4864:20::1042]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4ABA3C0613B0 for ; Fri, 25 Sep 2020 12:42:40 -0700 (PDT) Received: by mail-pj1-x1042.google.com with SMTP id u3so54077pjr.3 for ; Fri, 25 Sep 2020 12:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=1VTbmlxP/NBx4Wl43Zwmsnljn3SCRy51x1r81CV0BZM=; b=dtRToJmyHTTr67lrP3SrUIoLxJrrKsByqQJ1DZqoALfG2zQF4UhGdYQvTnp8NK+c8D WvYzv4Xi3KqVHy8qs+yI4HHZLz2S644qeifFYle7DzsHYiTpCwSAc5aDg9+Kc2qNouQm 4lO83kqhdbxY461s8apYSrnvsCnFPC2jx1V7U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=1VTbmlxP/NBx4Wl43Zwmsnljn3SCRy51x1r81CV0BZM=; b=Qkmi7Zi5Tx7CfXo3ZgRaMXDva2ONxa7ujrjyTx7XBJ8ux+/Jq2NdR3ej+FTnT4xEkp YmrL6tz7nJL+NjlSAUXYX3JZJof6UwTt3Ht8P5tiSpuwBx19aPlKYCiuQfMjS3rfa3fj SzXjXBTg1u94KSscK9RIF4LYYgjd8JvrxJehkC56f8VVGJjtp/wCm/4Ez80HS8A1V/2V QtJ3LKsIYyXgipyuYEPuZqcU3zT/nKJ7HUiBM8ZTPSgr7Mu6oel2k2UPg8s1UVBa34IX CC1KeBRCidaOLTTlTY70vlRweDPBQI+wCnTGLybFrTNYHm+cSsLonWGai/p4Eph0qJ2V XBcg== X-Gm-Message-State: AOAM531m0BrUsSry9uETIJrnY6ofgYADkcarg/g5iWaOLiRLDfnaO0sx xVWEk19S/uWqPbozpji81VIBHw== X-Google-Smtp-Source: ABdhPJzf8ii6Mz6aePsI1Nr3EqtgEdasIytrUnQQEYjVuc6D6GJRGQUbTLrAOQNeoMvoaFUsDiVHrg== X-Received: by 2002:a17:90b:a0a:: with SMTP id gg10mr170348pjb.20.1601062959821; Fri, 25 Sep 2020 12:42:39 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id kk17sm26681pjb.31.2020.09.25.12.42.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Sep 2020 12:42:38 -0700 (PDT) Date: Fri, 25 Sep 2020 12:42:37 -0700 From: Kees Cook To: YiFei Zhu Cc: Linux Containers , YiFei Zhu , bpf , kernel list , Aleksa Sarai , Andrea Arcangeli , Andy Lutomirski , Dimitrios Skarlatos , Giuseppe Scrivano , Hubertus Franke , Jack Chen , Jann Horn , Josep Torrellas , Tianyin Xu , Tobin Feldman-Fitzthum , Tycho Andersen , Valentin Rothberg , Will Drewry Subject: Re: [PATCH v2 seccomp 3/6] seccomp/cache: Add "emulator" to check if filter is arg-dependent Message-ID: <202009251223.8E46C831E2@keescook> References: <202009241601.FFC0CF68@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 25, 2020 at 11:45:05AM -0500, YiFei Zhu wrote: > On Thu, Sep 24, 2020 at 10:04 PM YiFei Zhu wrote: > > > Why do the prepare here instead of during attach? (And note that it > > > should not be written to fail.) > > > > Right. > > During attach a spinlock (current->sighand->siglock) is held. Do we > really want to put the emulator in the "atomic section"? It's a good point, but I had some other ideas around it that lead to me a different conclusion. Here's what I've got in my head: I don't view filter attach (nor the siglock) as fastpath: the lock is rarely contested and the "long time" will only be during filter attach. When performing filter emulation, all the syscalls that are already marked as "must run filter" on the previous filter can be skipped for the new filter, since it cannot change the outcome, which makes the emulation step faster. The previous filter's bitmap isn't "stable" until siglock is held. If we do the emulation step before siglock, we have to always do full evaluation of all syscalls, and then merge the bitmap during attach. That means all filters ever attached will take maximal time to perform emulation. I prefer the idea of the emulation step taking advantage of the bitmap optimization, since the kernel spends less time doing work over the life of the process tree. It's certainly marginal, but it also lets all the bitmap manipulation stay in one place (as opposed to being split between "prepare" and "attach"). What do you think? -- Kees Cook