From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f175.google.com (mail-yw1-f175.google.com [209.85.128.175]) (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 8CAA645C6F7 for ; Fri, 7 Aug 2026 22:00:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786140015; cv=none; b=Ut1i96f5T2ScylzGLFv3WmcrHnK4LTRVjL45QvUeFNsjxXYk65YC2uft6OGPzvw3okoJzZoPU1xURC/UltwOBwkwjpMoZgIVjJnS7gbRECa5Jvp3jiP112zWIGuryB5mVXcUGSVHDCnIn6xWNcNVW8npIcVITe1CJaCDQpyhBxw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786140015; c=relaxed/simple; bh=nU54FZpSFFu4P2NKSM0v6X4FpyUhXD5t5Vyi5Gc8bR4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=RiCeBpCqqeseoF2Yhyc9Us732U0ly3/+BnHdtrLPCatvPNI7REycS19eawYfMxy+6C0koAeAVv/rzvs6X6XFEcYdTumM8ANOeCeAiZP6SU0Vgybt8ZW+lsnvcCDnEjHKdWH0rJikcLOyAwsM0rSp2vkDwtXii9BVpfataJqpSD4= 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=e6K4QxPa; arc=none smtp.client-ip=209.85.128.175 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="e6K4QxPa" Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-80e24970f1dso89867b3.0 for ; Fri, 07 Aug 2026 15:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786140012; x=1786744812; 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=n/SAijTGHhHzvlBvPCx6AlmHoiuAwRn2jXN8unnNebg=; b=e6K4QxPaPL7ddQfOdqkiVqnY2amb//lhs92Dm1xvhj6krBkHfsOnuc/eIP4UvijX6c xckK9f/7tXOYzufaKcQXS0p5NR1JCSIC6x4D6nx7iQTGbMkk6NsA8R4R/6NqHc3EuNVY kcOLCyikGMiKC5u1iInrygqxbKZJQ5tO9QtE1r67fjFCFuQ84AgFu7yuaCiJi8nJrrVk rxjhmo2B4p8CsxnCvBIdDSIpUHkRRrmAz9q5DpIC0ZloP2394Fa8Bb7XrGbgdMTK8I7V 0OuW+SB0e2gaTfA1iTteMwzqsIOXYqzrUTbzaonMAxebZ2yb794a8itm+FdbDyw9DuAy wgrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786140012; x=1786744812; 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=n/SAijTGHhHzvlBvPCx6AlmHoiuAwRn2jXN8unnNebg=; b=SL47McTbPGwGHdH3J6hUucO/X4QmAGcMnSbEyuvAHAJDUaIwnYsydju100DXx+8Qkq IHu6luG78+dmevHbRjNNW4+7OLw9TQy73v+eLKnC+sc/7mWdKzIrDtcls4khNMTmpIOV Xl9it1qhUqpVEp9NxOm6q6LwG39KQGSc1mAV47LsucBi/dRutkPez54SjTKmbxSxBF82 VGvvZKeOPiItMWdOCveQmP+ngyzo0hezpJuLueMs0ZBZYBhd8ZqF0u8VrjlT6RkVvcXq ft4WZdKAEzyJDxXVF3CMtqUxQg0bF6TsnxKSDLbcwGewOL/4+lq8/hOBBXafUgrLRmND Z11g== X-Forwarded-Encrypted: i=1; AHgh+RqKYRGRyxC3jPMN1aqiS1BjA2WNmfTStPm+mOGkIeBS+vB6CBwPJfHOQMO5VYM7JGgwCOd4jm7VbRQv6As=@vger.kernel.org X-Gm-Message-State: AOJu0YxCHR7avCOS5JhQ41FL/vvegzNdJ9y6IKUXy7V2Ao/TUCyAmdOM O6CwUrcYTt71MOSxJU1IJQRMr3DZyZghLbQ5PpnWfMQVbPvvlSgSLSeN X-Gm-Gg: AR+sD11FUTqWOhZwjgXCEwLRf1XfuM520V9XRJm8QxGsvTZOPUkrHqnYOhYv3kT3g8+ Jam77VWslUeT5QRYJyLfD8S4seRD6LAMUBofJ/2+vBgyttZluveM3EdMJnwUwWeXr7cPEyADTDD w2GA3EfvjRe4RUy+20GT9KWDuM1Bh6bcm5e4ZD/8w2a5BMgU9uumzxL5boDHibJIRzqwgGnKCai IgVeWZGU24u/owKz/0k/Yl/AL3ybt/8x5ElKWKHTGFqWPsghMkrQug4z4qhtI1XpM7i9T0h8E28 F+H3MCpiyiv9mE0YxcQxRMtEE5E5LvPvKtBnJsMgg21IHLIhz2PY5flSt9qRND1JQYIhXxXFrny CUumLoZA40OB/4tSiZOIWiMWBtZnjinuMDHEF7V1d6E80ZXABdjAMmc9vPjFuLztysSWYst50WB 17g9WN+gYsAIvzTDfX21jBYXua5KgPvsrR2varMb3/xEdi0nxQD5WMz0xC2KwAfp1gB71kJmiAY jhNfAI4+QX3Lx4Aoip5lXQ= X-Received: by 2002:a05:690c:9689:b0:80c:3848:bde5 with SMTP id 00721157ae682-82258a8f2dbmr74464677b3.13.1786140012233; Fri, 07 Aug 2026 15:00:12 -0700 (PDT) Received: from zenbox ([2600:1700:18fb:6011:30b1:d824:50d0:7b8b]) by smtp.gmail.com with ESMTPSA id 00721157ae682-823f07a3246sm16925817b3.17.2026.08.07.15.00.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Aug 2026 15:00:11 -0700 (PDT) Date: Fri, 7 Aug 2026 18:00:10 -0400 From: Justin Suess To: Paul Moore Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, kpsingh@kernel.org, mic@digikod.net, viro@zeniv.linux.org.uk, brauner@kernel.org, kees@kernel.org, gnoack@google.com, jack@suse.cz, song@kernel.org, yonghong.song@linux.dev, martin.lau@linux.dev, m@maowtm.org, bpf@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH bpf-next 00/13] BPF interface for applying Landlock rulesets Message-ID: References: <20260731022047.189137-1-utilityemal77@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@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 Fri, Aug 07, 2026 at 04:36:20PM -0400, Paul Moore wrote: > On Wed, Aug 5, 2026 at 8:32 PM Justin Suess wrote: > > On Wed, Aug 05, 2026 at 06:51:56PM -0400, Paul Moore wrote: > > > On Wed, Aug 5, 2026 at 5:37 PM Justin Suess wrote: > > > > On Fri, Jul 31, 2026 at 04:30:39PM -0400, Paul Moore wrote: > > > > > On Thu, Jul 30, 2026 at 10:21 PM Justin Suess wrote: > > > > > [...] > > > > > As you may, or may not have seen, there is currently an ongoing debate > > > > > regarding the location of LSM kfuncs that will impact this patchset. > > > > > Sadly, we don't appear to be approaching an agreement on this issue > > > > > which introduces some additional risk to this patchset. We'll have to > > > > > see how that ends up, but I just wanted you to be aware of the > > > > > situation. > > > > > > > > Quick aside question: Would security/bpf/ be a better place for these > > > > type of kfuncs? > > > > > > > > security/bpf/bpf_lsm_kfuncs.c could be for LSM framework kfuncs, > > > > and each LSM could maintain their own security/bpf/_kfuncs.c > > > > for kfuncs dealing with lsm-specific types. > > > > > > This gets back to the other issue in the patchset that we've > > > discussed: general LSM interfaces vs Landlock specific interfaces. > > > There are plenty of reasons why we don't support the kernel calling > > > directly into individual LSMs, and from my perspective this is another > > > > I'm 100% on board with the no calling directly into individual LSMs part. > > > > > instance of that. Here it just happens to be that the kernel caller > > > was written in BPF and not C (or Rust for that matter). > > > > The intention is the opposite. The point of the separate directory is > > that the kfuncs can never call into an individual LSM, they only get > > the LSM framework API in . > > > > Every kfunc is a thin wrapper over the generic policy kptr hooks: > > > > bpf_landlock_get_ruleset_from_fd() > > -> security_policy_kptr_from_fd(LSM_ID_LANDLOCK, ...) > > -> Landlock's hook implementation > > > > So kfunc -> generic lsm hook -> individual LSM, same as any other > > caller in the kernel. > > Not exactly. That "bpf_*landlock*_XXX" kfuncs are a move away from an > LSM agnostic API and not something we currently do in the kernel. > Some will, and have, argued that this is more akin to the Landlock > syscalls, but I see (at least) two problems with that comparison: the > kfuncs being presented aren't syscalls, they are cross-subsystem > kernel function calls; the Landlock syscalls were created in a I see the argument for normal in-tree kernel interfaces. Unlike normal kernel interfaces, kfuncs: 1. Can exist without in-tree callers. 2. Are explicitly allowed to change or be removed at any time [1]. 3. Can't break builds or other in-tree subsystems when they do. This isn't hypothetical: the entire KF_KPTR_GET class (bpf_task_kptr_get(), bpf_cgroup_kptr_get(), the flag itself) was removed and replaced with a better abstraction within about a year of introduction. If Landlock (or any LSM) dies, there's zero uapi/in-tree cost to removing the kfuncs, unlike syscalls which are burned into the uapi forever, or ones with in-tree callers where we can break builds. I argue that the transient, low-commitment nature of kfuncs mitigates maintainability issues that arise from lsm-specific interfaces with in-tree callers. (which we are both opposed to). > different time, today these would need to be reframed as LSM > syscalls*. > LSM-specific interfaces exist both in the LSM syscalls and in my design. The only disagreement we have is the abstraction layer that the "LSM-specific" part comes into effect. 1) In the lsm syscalls, it's inside of the lsm_ctx and the LSM_ID. 2) In my design for kfuncs, it's in the function signature and the kptr types. It's fine to have binary blobs like lsm_ctx where we always assume userspace is untrusted. They can pass garbage through the syscall that we have to handle, which is expected. BPF and kfuncs are a ring-0, kernel internal interface, trusted after verification. You can't cast pointers, or deserialize them from binary blobs like lsm_ctx in BPF. The ownership and types of pointers must be verified at load time. kfuncs, their annotations, (KF_ACQUIRE/KF_RELEASE) and kptrs are the primary interface by which BPF checks correctness. An LSM-agnostic bpf_lsm_policy_from_fd(lsm_id, fd) multiplexer would lock every current and future LSM's policy object into a single set of lifetime and context rules, and would move type errors from load time to runtime. This would prove to be less maintainable, because the main way of ensuring correctness (kfunc signatures + kptr types) would be taken away. To avoid strawman style arguments, I ask what you would see as an alternative interface? Justin [1] https://docs.kernel.org/bpf/kfuncs.html > (* To be clear, we're not going to remove the Landlock syscalls for > all the obvious reasons, but we're also not going to support APIs like > that unless we have throughly exhausted all other options.) > > -- > paul-moore.com