From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (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 B9AC04A8A2D for ; Wed, 2 Sep 2026 15:20:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788362433; cv=none; b=c8pRZLp6siZxWZfqPOfZnLg5Jb20pRYK6GWEdWKqPpvir4K+t59yNTy4dhunZpi789TtZt2riBAoT552GKVsGOxspUg2unBth+rNwCpmY72a5SGaaLCbXBHReviSMqCNR0I22NbJxkzeiAF1MD4ZwpILmd8gNlCETuQ6LG7J9CE= 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.46 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-f46.google.com with SMTP id ffacd0b85a97d-482e61a34e5so486203f8f.3 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=A3WYdT3VL6Gdx/cgsMjd/GkhcyFGSo0sLLZuq1YSvmQ/pfBkvC58mGQXUmZkB4Zxg1 8zbZk3b/GyAglrQ6PYFtytK7EADCoGnqJunR0lepIg/BiJ5qDSrcLSzbTWcWLLI/sgoB s7qkrP9cr3bqt1IFkKUR3+TvWpb23chOvXfsXaHGyvTr91r5PcYG+SWZ9fP0yCpvFbfT 5AZ7lse+2WLsA/+Lclvq0M5FGBM/ekSvBNZzOlFomVV0o2idp6DailBPPTdLaFFGBUrQ LXBjfYAi7OwpQG2bX5h5AxEQmp1ytqauVNSZag7VYGtpPIRRuaC9wDCHwGgnbQlqdiAl gePQ== X-Forwarded-Encrypted: i=1; AKwUvBweRXCrASF0RAueUl2I+u0LQcaJP8j8oU42/hUwFcfb0gduoCVXMMsAyiE/IJnou3TUY02QI0I=@vger.kernel.org X-Gm-Message-State: AFuF++ksVWmzPT7QaopEGq8TkxGjF4wkz7unSJAde1pENf2vUjjreSso cJSNFw2zTNpFhxHCMRO3nfFDUTykvNTihN1Sfdtsd21G7JB2TlShQ3dl X-Gm-Gg: AYBFou3pm3KJI/rxKXB8xa/BFUVnPpVJq3sMqc4gjrjqeFzhsICxzIpOe42Km28s5oH NaP08Uor3i1Ohlak3eUPoMWtb5by3cgOtcAKj6KC1C0CUGQAWyH8SiJfxpyGhe7NqIvgPIve2Qg 6zRAcJ8sAvFZJXVMnm9fOtUpbcLvZrMX0NPXJ6NZNnKuiWOgYF8URgU/8Dt9oMqXTVtJ+Bj/Vgz dbgQcLC+pUx1qgd7xp+zY4jCzCUvwF+zxm1w/Tk5cbSDTwQrzp63Df5Md2qCU7lOpUqUmdCsJV9 0UNwHRu24Y/Lf7psokOgQmSyaF+Y96Y0WU101uXt/3s3fKRJangxmWrnDQ6VPZtP4xChTGRG+WC 3d/jfORladXdWuFqD8sCVg5PeV54jTxYyx1gegLL+haiBScHPlOaxEkEsg4p68rXUuFZR9jnfJ8 blugWZDlCjk50y0+baiyYNKlIMRVXKLYReXy3v73wRS6BoQc4djXQdyvAf5l0e13yCEZMv 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: netdev@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