From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f169.google.com (mail-yw1-f169.google.com [209.85.128.169]) (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 0D26A1A682F for ; Thu, 6 Aug 2026 00:32:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785976340; cv=none; b=o5iXyu8iL6CdB++bTKAn+1FjRG/uTDmq4D47meYY/6djz9SV+6a3J3vFgdyRMMytt7/GNn1BhmwR5NOJpMcbiz3Z8FhAJB0bGWUKohwyeRV1CaWw68Jr8Q3SloPCs6t7SphBoV2wdIDdI3gUhj4/8bdwuwpXL8I++lYUjjrJLnQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785976340; c=relaxed/simple; bh=t151uzynxLJ/WULoxogSTwfKcoLQQ946O1PY4MkYhvA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KrbdS8w1joDb7uNqUkVuTjahcEG+GsJtAk6KirguniBc32Z01BDFIh74parPOC+aJahJ6cqdSaPqQjYf0Q8tj2CCbkp8W2R6N1FOrdISSISpzYT2eaLhDF0v3NR0jiEay0AIL2tmOFRtL0ssvePchZ1vkcBclBkNMRWdd0mXido= 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=BEMPPHG0; arc=none smtp.client-ip=209.85.128.169 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="BEMPPHG0" Received: by mail-yw1-f169.google.com with SMTP id 00721157ae682-80e24970f1dso13080147b3.0 for ; Wed, 05 Aug 2026 17:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785976338; x=1786581138; 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=2F8fXV8jMRshW9OPPH/zGJGmCPAHy4asEUrxhxRVPHU=; b=BEMPPHG0FUMbv/RRb5aI6DnmumArWixc2Swg9aG/1MUqco5RuEbnu48yYX4pUAmbV2 nFcr89Tf8y9uUyatESS7SHMOOpcAvp6Lb+beSgTOIAD/a6vI+xEvaKxxq3Cudw2KmQL1 4BLuALB0KPmad02yoTcW0/yJ0aV2Xq/t7o9J2SJ9ahF0VYBKXX8lV3ge5FzWayHtMa1h e+MplLNQU8FaTZY5CnqkO07QW2zdwA3ee4ez/54U9yVDuZ/lx0bIamk/iy1t/P5ytMiQ ebWQi1vvbM1p2+iB8tW4iR/+EmfTjlxZZ3wkSP9Ng+nuRUjSDnZMW4vebuQnm8flV8MX jdiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785976338; x=1786581138; 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=2F8fXV8jMRshW9OPPH/zGJGmCPAHy4asEUrxhxRVPHU=; b=Krs2ZWjmzREfVCNYnQAzAarWG28IH6lFaCLPJh62YmsUzddZz2r9M/ZxxkCFZjwMAP QC2P+K36HfcyvdlZ2Wnd2ohREhfcCs/ejIcyqFwC9Z8CQjubSFSgxg8RVn4EuEoJipag +dmCiB0CgoIUM43BBms/Dy8ztXwHGGyqe+XG+Srq884APG+M0BEub1KvylZ/uD5fZO6L nzWdDQ8e6AIzDtZ/5ImB+5VpesUAg6IRqbnuaUa3sSybZEnXrUSV/maD/62eKXqZ9OIW 9Uz2XuHheMQIrs6PUGOtkuSpQCWt9uQxUAftCcr2qkPSyuGlcpVfOR0/+P/0fadEB6Km 5bHg== X-Forwarded-Encrypted: i=1; AHgh+RodSPq6rdVaTD4PWcyPGpvtSfmLROetvXZU8H9vUevY0jGE/syuXTeGcmUlR0Rdu3Vi7TJaIQ74BQ7wVJY=@vger.kernel.org X-Gm-Message-State: AOJu0YwrSmfe6vY0N2n2xOrmdGaaJChIGreqVkuk7QCpoH77j0h0hjnq /L4w9NRKcrna39EuSpW0Lc0ofyiAIDNpgTgMxGiAqQb2U6cTHa60eleP X-Gm-Gg: AR+sD13BKCLrU7Zh1RjXlBK14Ci+G8+mE9Ia5Sa1PhEgswf59uxJLal3yW+3/bUd3gr jszvrD8zlqp8p5yactT1W96TWubZR/oxGzHSV60NM7opiO5uVyGm2k4W5sTbBcQey958S6wp9Zl 9lwOCe0zoEdI1TtxL6OHN1QNRbOv9+cHxKpEVZYa8V1ulnbEkVFbmu2C9AuRaxuKMupOV00Wi3W pLYmMr80jpVqxWz0PeTrQ2mr1WPRbyQtwoaoYL4MUjD8/uXyhfLqrjfGM1dZGQOj+M6nMBsDlwY OkRWAb0O7HSXneomCyLwKkFPWSzXrYlnXySGmfZ+SyDaYDmWypU0BpugOR/pGhqURxse4ZUUPlK XvV3pz+0F1mUHgeU93SFFMqtQYTTuqBr95BxsCJwBsnBGUs6c0brOnY8eS1ajSC+0/dIpeKO6J7 45TmRwYLe/TvjuHL+HrOEm9yAWM6vKkglmzNkfLSupcpjur7m1Bd8A7TDjzTIBJx9KopliEIW7x FltLXVtVCwHjs/PBuRF72Y= X-Received: by 2002:a05:690c:4b86:b0:81d:e7d2:a46d with SMTP id 00721157ae682-8201bc73840mr64948197b3.5.1785976337931; Wed, 05 Aug 2026 17:32:17 -0700 (PDT) Received: from zenbox ([2600:1700:18fb:6011:7d5b:ac23:cde9:3664]) by smtp.gmail.com with ESMTPSA id 00721157ae682-8201341d3d2sm29635727b3.31.2026.08.05.17.32.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Aug 2026 17:32:17 -0700 (PDT) Date: Wed, 5 Aug 2026 20:32:16 -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 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. There's no build dependency on Landlock either: the kfuncs register under CONFIG_BPF_LSM, and if Landlock is compiled out or not in the lsm order, the hook dispatch by lsm id misses and the call returns -EOPNOTSUPP. The only Landlock-specific part is what the BPF program sees: the kfunc names and the opaque handle (an empty struct bpf_landlock_ruleset). Permit me to use SELinux-specific interface through LSM as an example. The existing userspace API already has this exact pattern (partially from [1], thanks Casey it was a great talk!): ctx->id = LSM_ID_SELINUX; ctx->flags = 0; ctx->len = sizeof(struct lsm_ctx) + ctx_len; ctx->ctx_len = ctx_len; memcpy(ctx->ctx, "unconfined_u:unconfined_r:foo_t:s0", ctx_len); lsm_set_self_attr(LSM_ATTR_EXEC, ctx, ctx->len, 0); If you think about it; that's what this patch is doing! "unconfined_u:unconfined_r:foo_t:s0" is as LSM specific as bpf_landlock_ruleset* is. This is a generic framework syscall, targeted at one LSM by lsm id, carrying an LSM-specific payload. Our kptr is basically the lsm_ctx; the difference is that the lsm id and payload type move out of runtime fields and into the BTF type, so a mismatch fails at program load instead of at runtime. Much better for security! (fail fast and fail hard) The verifier is why the lsm id can't stay runtime data the way lsm_ctx carries it. Say LSM xyz's policy struct is protected by a mutex (the caller must be able to sleep) while LSM abc's is accessed under RCU. Those rules are enforced at program load time through the KF_* annotations and argument types of the kfunc itself, so a single generic policy kfunc can't carry both. Per-LSM kfuncs above the generic hooks are what let the verifier *prove* each LSM's objects are only accessed in the right context. Userspace only gets away with the fully generic lsm_ctx because its calling context is always the same: syscall context. BPF programs are everywhere from syscalls to LSM hooks, so the context requirements have to be part of the interface. So I don't see these kfuncs as a Landlock-specific interface. They're the same generic interface the framework already gives userspace, with the lsm id and access rules promoted into *types* the verifier can check at load time. Justin [1] https://static.sched.com/hosted_files/lssna24/1a/2024-04-LSSNA-liblsm.pdf