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=-3.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FSL_HELO_FAKE,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 B613CC2BA83 for ; Wed, 12 Feb 2020 16:26:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8643520714 for ; Wed, 12 Feb 2020 16:26:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="YpL67d8O" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727600AbgBLQ0S (ORCPT ); Wed, 12 Feb 2020 11:26:18 -0500 Received: from mail-wm1-f68.google.com ([209.85.128.68]:54785 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727429AbgBLQ0R (ORCPT ); Wed, 12 Feb 2020 11:26:17 -0500 Received: by mail-wm1-f68.google.com with SMTP id g1so2995280wmh.4 for ; Wed, 12 Feb 2020 08:26:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=+Oq1AdUw8m9+Ejebod5uLNgdGrkCleSq0Jc+gdcY2Xc=; b=YpL67d8OFfQLpn88KHHeHpPU9M5tKjVFTcgq5WB9ADXua8Vw9eM8D2prp/DJjWvw5x IUn9CPoWMY9ErauDjliaZ0oyal2LyauacKjUhMC9MEyWAKMtuwKlz5y5xltvAr5Xm+4a LxQdRjGor2YzOi0pqFDJ9uvpsP70D/2xy3qaY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=+Oq1AdUw8m9+Ejebod5uLNgdGrkCleSq0Jc+gdcY2Xc=; b=AfvaVP+bQLuqYDQEB4qYM6x4q2CZ7xxtAgII/Wmr354H8E7gEGD3B+XtEnr7H62qWH ElnYOCoOLSjN/QZJe6uuAXGJL5zjWUsKe5k8A2kA0/Ddw/whTJNihyHlMB53UvNTzA3a NzBFPT+sfScSulUx+C46f2u9m4n24xG3K2fPe2pULtViHs2j43IAsYu7rQMYm3uMwiig 8KDGQT/Kqdr/am/dA1Kvf2JKzRx9t/rXTrqccmZOfdJ1ciC8lnwfjEXLd317KV6rjHTc RMCOSYmb5IUCXo0RCiT9lJo9Fj4o6Olvh98S1U8X1xjDbON0aU9MeO5X7gCl+w7WgMm7 Z+4w== X-Gm-Message-State: APjAAAWIW7heZibnW1joyfaGd/oNoNR5HcF9WmTPvEnsVARtarTHfeB/ GRk8/wgvifArjWY36q01a0kS4A== X-Google-Smtp-Source: APXvYqz35eTpzE3tOLY8FLLO74LVWtEJvvI50Wec8849cwajczF2fVsNZaWwaW+IbhiJCYa0NkM9Lg== X-Received: by 2002:a7b:cab1:: with SMTP id r17mr13425209wml.116.1581524775975; Wed, 12 Feb 2020 08:26:15 -0800 (PST) Received: from google.com ([2a00:79e0:42:204:8a21:ba0c:bb42:75ec]) by smtp.gmail.com with ESMTPSA id s8sm1267535wrt.57.2020.02.12.08.26.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Feb 2020 08:26:15 -0800 (PST) From: KP Singh X-Google-Original-From: KP Singh Date: Wed, 12 Feb 2020 17:26:13 +0100 To: Casey Schaufler Cc: Alexei Starovoitov , Daniel Borkmann , Jann Horn , KP Singh , kernel list , bpf , linux-security-module , Brendan Jackman , Florent Revest , Thomas Garnier , Alexei Starovoitov , James Morris , Kees Cook , Thomas Garnier , Michael Halcrow , Paul Turner , Brendan Gregg , Matthew Garrett , Christian Brauner , =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= , Florent Revest , Brendan Jackman , "Serge E. Hallyn" , Mauro Carvalho Chehab , "David S. Miller" , Greg Kroah-Hartman , Kernel Team Subject: Re: BPF LSM and fexit [was: [PATCH bpf-next v3 04/10] bpf: lsm: Add mutable hooks list for the BPF LSM] Message-ID: <20200212162613.GB259057@google.com> References: <20200211190943.sysdbz2zuz5666nq@ast-mbp> <20200211201039.om6xqoscfle7bguz@ast-mbp> <20200211213819.j4ltrjjkuywihpnv@ast-mbp> <1cd10710-a81b-8f9b-696d-aa40b0a67225@iogearbox.net> <20200212024542.gdsafhvqykucdp4h@ast-mbp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On 12-Feb 07:52, Casey Schaufler wrote: > On 2/11/2020 6:45 PM, Alexei Starovoitov wrote: > > On Wed, Feb 12, 2020 at 01:09:07AM +0100, Daniel Borkmann wrote: > >> Another approach could be to have a special nop inside call_int_hook() > >> macro which would then get patched to avoid these situations. Somewhat > >> similar like static keys where it could be defined anywhere in text but > >> with updating of call_int_hook()'s RC for the verdict. > > Tell me again why you can't register your BPF hooks like all the > other security modules do? You keep reintroducing BPF as a special > case, and I don't see why. I think we tried to answer this in the discussion we had: https://lore.kernel.org/bpf/20200123152440.28956-1-kpsingh@chromium.org/T/#meb1eea982e63be0806f9bba58e91160871803752 BPF should not allocate a wrapper (to be statically regsitered at init) for each LSM hook and run the programs from within that as this implies adding overhead across the board for every hook even if it's never used (i.e. no BPF program is attached to the hook). We can, with the suggestions discussed here, avoid adding unncessary overhead for unused hooks. And, as Alexei mentioned, adding overhead when not really needed is especially bad for LSM hooks like sock_sendmsg. The other LSMs do not provide dynamic / mutable hooks, so it makes sense for them to register the hooks once at load time. - KP > > Sounds nice in theory. I couldn't quite picture how that would look > > in the code, so I hacked: > > diff --git a/security/security.c b/security/security.c > > index 565bc9b67276..ce4bc1e5e26c 100644 > > --- a/security/security.c [...]