From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A20B54A8A0E for ; Wed, 2 Sep 2026 15:20:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788362433; cv=none; b=iv08jEdSqSJkbEXHvKfGGxwgK1cL7OwSerBIrAtH7MF2uy2RpQp/yG8uwJVYYX+XvJfevbolti6uRDAQYrT9ozwB0w6bEf1aWx+ZxTsDFQA675uQJK2Hbpn6Bo2Q5zAtEmdZ71BLSvReuLO9Jg0e800v73DKzV5WSUFGw1pNCVQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788362433; c=relaxed/simple; bh=7xuDMIlFysPCGTCdJAsweWLwA/wrkwLbnesyHF9L3Cc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PGczTvElzmxxJz8b3MoaEpQ2vJZVoi6jxqFndoVVeA6825QD7/V+KnxWqb0BG32iqlfDLXM662FOQCMxaXjKzRsdS6ZThVVDOtBxbsefNP35jO0unflC3OGDD2iJTg3Y89xW9H2nIXRUAzuBGw+YrKm5pa98RQRu/X2NrMFzqtU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=rJ7T+BOJ; arc=none smtp.client-ip=209.85.221.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rJ7T+BOJ" Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-482ea739de2so695492f8f.0 for ; Wed, 02 Sep 2026 08:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788362430; x=1788967230; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to:content-type; bh=Ba9zSR0pFL6J1qeSltvfRoRTGU1ERDBWr20h/vbRz9o=; b=rJ7T+BOJsKL8xsUmp8sVc2QQI3Qfs5ycY8z05IP/J+zPtC8yJQzOSFzV71byya2IyT VJJVtQYsm34uGhNMWTVUtGOwKPQWdyaojOT8/vDq/ufacMbrEvHep7limHrCuS/d5yer fmKelJWPD7hMDcYCFSVkyPHud3Cdf2M+I27i/VNERvBEik8rVFSWuLfgdFsMxoIL4A4i BNw4/8KtX2SosfwOwGMRR/5tx5nlmOUo8ctLghp3QxJvi+2siOVT8AnKW+NpRWMbkLK6 O291vZrpaAHvEg2OJMB+5mOgnuSeSoCkn7VNFMetYLLRkAsyY7nBmaLEYy6KOKSlGT8+ OLNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788362430; x=1788967230; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=Ba9zSR0pFL6J1qeSltvfRoRTGU1ERDBWr20h/vbRz9o=; b=pf+CHQuw2ncpWmTkfOxjUl1MzF2CrwUif64Kk673a8tSDk5pWGYnO+0amm3Z1rnr7f mekij0RFrZsKV8Ex+DFpDSLQBEDDekFz2Pb7hkii/r27haEnHyt9n3BksUr4ZcheJ0Jp pafXDWYfoIbT784u9LpLasTNA7voFMFCQ8kdzNyZkp9DVSWUlRWOtsiZ8EG8LSFc53Zw 9YhkExccCjDlEYceL33r8wLRd72sooknPN4b+qS2PHm12QJZmHhoM8nhA7IDiXLvTill JV1dyhLf7KMRSyPAt+q0JAu1Ceupfouk6lHln0OPq6ehKHNic9PzQpTAo+lNZlHwhuFD 9LBw== X-Gm-Message-State: AFuF++nHdFjaeCGP01zmj0aaRWK+ighdrEhOeJRuZ3PRWUGQTJR/mz+w eJf6RtCi+k5cLyXNEkdkaSOZlnPJwGMXzs5OBT3Frv6afR9cH3F4frP4 X-Gm-Gg: AYBFou1PiuztIppeKIwdeoKWhPDzc+ja1FZSJOQ3e962tMkRWTMvxIevciUVCi15N+m jtbTqNs2GEYg3KDb1x1QtkgZnfi3Z4Do2f3Tl/sjnpirfJ+qA0pRPHDDPMhA6LpvHIbJS3xS8Jq vIbetpxbVSLvSAX7wkjFmrSDzgHU9arDHENOSHdXS0qDAygHrVOGWc7W7KuZsd/LMbopeeMTAuN qBUBm3AgcO2YfLFYmnHtJMx0cQUSHvNdxxJnO+hBGGGUpNAxBOEPCJY6dOkEdKAIaBpo0MWoVAA dz//qemarXFxExxsE5Wm95sQyg72vFrPFO3JMv4PlXt1LzN+tsbewb/eckh/ps6xvN54of9qXCY r8eSZtG4WIQdr9E+1Id2rnzn8b6bqlRyRPxmMCXkBqVb+LGIt7wm+M3MAg+znp2n27yf1Hu/ozP jjlaff5DVivJQ7UCwRoLQXcezayMqBdFEmlzY06WQfQLbop1mdy21pA2D9g1SaYdyvuETz X-Received: by 2002:a05:6000:71c:b0:482:ee81:f0ca with SMTP id ffacd0b85a97d-48488dfd8bamr12215044f8f.12.1788362429459; Wed, 02 Sep 2026 08:20:29 -0700 (PDT) Received: from mail.gmail.com ([2a04:ee41:4:b2de:1ac0:4dff:fe0f:3782]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48448e72c28sm7368681f8f.6.2026.09.02.08.20.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Sep 2026 08:20:27 -0700 (PDT) Date: Wed, 2 Sep 2026 15:31:02 +0000 From: Anton Protopopov To: Paul Moore Cc: bpf , lsm , netdev , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , KP Singh , Matt Bobrowski , John Fastabend , Christian Brauner , Linus Torvalds , Eric Dumazet , Jakub Kicinski , Paolo Abeni Subject: Re: [PATCH bpf-next 1/7] bpf: Allow BPF LSM programs to attach to more hooks Message-ID: References: <20260831110934.241898-1-a.s.protopopov@gmail.com> <20260831110934.241898-2-a.s.protopopov@gmail.com> Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On 26/09/01 06:15PM, Paul Moore wrote: > On Tue, Sep 1, 2026 at 9:26 AM Anton Protopopov > wrote: > > On 26/08/31 06:42PM, Paul Moore wrote: > > > On Mon, Aug 31, 2026 at 6:59 AM Anton Protopopov > > > wrote: > > > > > > > > The BPF LSM programs are allowed to attach to LSM hooks, all of which > > > > are defined in the header file. From BPF's point > > > > of view the set of attachment points is defined in the bpf_lsm_hooks > > > > BTF set. By analogy with existing code, add a new header file > > > > which will also be included in the bpf_lsm_hooks > > > > BTF set. > > > > > > > > This change allows attaching BPF LSM programs to more functions. > > > > The actual hooks are added in subsequent commits. > > > > > > > > Each BPF hook calls a [__weak] noinline function each time a hook is > > > > reached. This may be too expensive for hot paths if a BPF program is > > > > not attached. A future commit will optimize this by adding a per-hook > > > > static key and inc/dec it on attach/detach. This way disabled hooks > > > > will be bypassed efficiently. > > > > > > > > Signed-off-by: Anton Protopopov > > > > --- > > > > MAINTAINERS | 1 + > > > > include/linux/bpf_lsm.h | 12 ++++++++++++ > > > > include/linux/bpf_lsm_hook_defs.h | 6 ++++++ > > > > kernel/bpf/bpf_lsm.c | 2 ++ > > > > 4 files changed, 21 insertions(+) > > > > create mode 100644 include/linux/bpf_lsm_hook_defs.h > > > > > > Adding new BPF hooks in the kernel is one thing, but adding new BPF > > > LSM hooks outside of the LSM framework is likely to be problematic as > > > these new hooks operate disconnected from the LSM framework (callback > > > and LSM kernel object state management). We've seen bugs in the past > > > caused by the BPF LSM trying to operate independently of the LSM > > > framework, something like this will only make that worse. > > > > Could you please point me to some of the bugs you mention, such that > > I understand exactly what you mean? > > The latest that I'm aware of was a few months ago: > > https://lore.kernel.org/bpf/20260628201103.3624525-1-mattbobrowski@google.com So, for this one patch specifically uses the same fix. > > I am not really seeing how the > > real LSM hooks differ from the ones added here (from BPF point of > > view, and the objects it can access via kfuncs/maps). > > The existing LSM hooks, LSM security blobs (the 'void *security' > fields present in many kernel objects), and individual LSM callbacks > are managed by the LSM framework whereas the functions you are > proposing are not. This is important because the LSM framework > enables/disables individual LSMs at boot time which impacts both the > executed LSM callbacks and the security blob allocations. > Implementing "hooks" that operate outside the LSM framework can cause > unexpected user behavior and potentially destabilize the kernel, > leading to a system crash. > > We require all LSMs (Landlock, Smack, AppArmor, SELinux, etc.) to go > through the LSM framework, the BPF LSM is no exception to this rule. > If you want to add additional BPF program call sites beyond what the > LSM framework provides, please implement them outside of the BPF LSM; > there is plenty of precendence for that already. Thanks, this makes sense. > > The main reason (for now) to specifically create a new list of BPF-only LSM > > hooks is (pcmoore/lsm.git/tree/README.md): > > > > """New LSM hooks must demonstrate their usefulness by providing a meaningful > > implementation for at least one in-kernel LSM. The goal is to demonstrate the > > purpose and expected semantics of the hooks. Out of tree kernel code, and pass > > through implementations, such as the BPF LSM, are not eligible for LSM hook > > reference implementations.""" > > > > And for the hooks added in this series > > > > a) BPF satisfies our needs, as we can precisely analyse what the > > calls are trying to do with good granularity > > > > b) I am not sure how to actually express this in any in-tree LSMs > > > > Can't BPF be considered enough to demonstrate usefulness? > > The core issue has little to do with BPF, it has everything to do with > in-tree vs out-of-tree code. The BPF LSM is explicitly mentioned as a > "pass through" because some have argued that the BPF LSM is in-tree, > and while the basic BPF enablement is in-tree, the actual LSM code > that is executed has thus far always been out-of-tree. Yes, the actual code isn't, but all the building blocks are. The BPF is just a sophisticated policy language, in which, given, say, ethtool hooks are present, one can say "block all ethtool ETHTOOL_TEST_CMD calls for the XXX driver" or so. Is there any way into turning BPF first-class citizen from LSMs point of view? > -- > paul-moore.com