* Re: [stable/linux-6.18.y 1/2] lsm: add backing_file LSM hooks
From: Greg KH @ 2026-06-25 11:06 UTC (permalink / raw)
To: Cai Xinchen
Cc: viro, brauner, jack, miklos, amir73il, paul, jmorris, serge,
stephen.smalley.work, omosnace, bboscaccy, linux-fsdevel,
linux-kernel, linux-unionfs, linux-security-module, selinux, bpf,
lujialin4
In-Reply-To: <20260622031416.2663747-2-caixinchen1@huawei.com>
On Mon, Jun 22, 2026 at 11:14:15AM +0800, Cai Xinchen wrote:
> From: Paul Moore <paul@paul-moore.com>
>
> Mainline declares lsm_backing_file_cache in security/lsm.h. Linux 6.18.y
> does not have security/lsm_init.c or security/lsm.h; the cache variable
> is defined locally as static struct kmem_cache *lsm_backing_file_cache in
> security/security.c.
>
> Original commit message:
What is the original git commit id?
ANd put the "changes" down in the signed-off-by area, like other
backports normally do please.
thanks,
greg k-h
^ permalink raw reply
* Re: [stable/linux-6.18.y 2/2] selinux: fix overlayfs mmap() and mprotect() access checks
From: Greg KH @ 2026-06-25 11:06 UTC (permalink / raw)
To: Cai Xinchen
Cc: viro, brauner, jack, miklos, amir73il, paul, jmorris, serge,
stephen.smalley.work, omosnace, bboscaccy, linux-fsdevel,
linux-kernel, linux-unionfs, linux-security-module, selinux, bpf,
lujialin4
In-Reply-To: <20260622031416.2663747-3-caixinchen1@huawei.com>
On Mon, Jun 22, 2026 at 11:14:16AM +0800, Cai Xinchen wrote:
> From: Paul Moore <paul@paul-moore.com>
>
> The existing SELinux security model for overlayfs is to allow access if
> the current task is able to access the top level file (the "user" file)
> and the mounter's credentials are sufficient to access the lower
> level file (the "backing" file). Unfortunately, the current code does
> not properly enforce these access controls for both mmap() and mprotect()
> operations on overlayfs filesystems.
>
> This patch makes use of the newly created security_mmap_backing_file()
> LSM hook to provide the missing backing file enforcement for mmap()
> operations, and leverages the backing file API and new LSM blob to
> provide the necessary information to properly enforce the mprotect()
> access controls.
>
> Cc: stable@vger.kernel.org
> Acked-by: Amir Goldstein <amir73il@gmail.com>
> Signed-off-by: Paul Moore <paul@paul-moore.com>
> Signed-off-by: Cai Xinchen <caixinchen1@huawei.com>
> ---
> security/selinux/hooks.c | 242 ++++++++++++++++++++++--------
> security/selinux/include/objsec.h | 11 ++
> 2 files changed, 189 insertions(+), 64 deletions(-)
Again, what is the git id?
thanks,
greg k-h
^ permalink raw reply
* Re: [stable/linux-6.12.y 0/2] Backport Fix incorrect overlayfs mmap() and mprotect() LSM access controls
From: Greg KH @ 2026-06-25 11:31 UTC (permalink / raw)
To: Cai Xinchen
Cc: viro, brauner, jack, miklos, amir73il, paul, jmorris, serge,
stephen.smalley.work, omosnace, bboscaccy, linux-fsdevel,
linux-kernel, linux-unionfs, linux-security-module, selinux, bpf,
lujialin4
In-Reply-To: <20260622031509.2663919-1-caixinchen1@huawei.com>
On Mon, Jun 22, 2026 at 11:15:07AM +0800, Cai Xinchen wrote:
> Backport the patch series
> "Fix incorrect overlayfs mmap() and mprotect() LSM access controls" [1]
> to 6.12 lts
>
> I test selinux-testsuite[2] overlay test, it pass 135 tests.
>
> [1] https://lore.kernel.org/all/20260403030848.731867-5-paul@paul-moore.com/
> [2] https://github.com/SELinuxProject/selinux-testsuite
Again, upstream git ids are needed. Please redo all of these and
resend.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] landlock: Documentation wording cleanups
From: Günther Noack @ 2026-06-25 12:29 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-doc, linux-security-module, Alejandro Colomar,
Alejandro Colomar
In-Reply-To: <20260516190112.4924-1-gnoack3000@gmail.com>
On Sat, May 16, 2026 at 09:01:12PM +0200, Günther Noack wrote:
> Documentation cleanups suggested by Alejandro Colomar,
> which we have also applied in the man pages.
>
> Link: https://lore.kernel.org/all/agW4yMK6CinJGqXt@devuan/
> Suggested-by: Alejandro Colomar <alx@kernel.org>
> Signed-off-by: Günther Noack <gnoack3000@gmail.com>
> ---
> include/uapi/linux/landlock.h | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/include/uapi/linux/landlock.h b/include/uapi/linux/landlock.h
> index 10a346e55e95..48c12ddf1108 100644
> --- a/include/uapi/linux/landlock.h
> +++ b/include/uapi/linux/landlock.h
> @@ -255,16 +255,16 @@ struct landlock_net_port_attr {
> * :manpage:`connect(2)` as well as calls to :manpage:`sendmsg(2)` with an
> * explicit recipient address.
> *
> - * This access right only applies to connections to UNIX server sockets which
> + * This access right applies only to connections to UNIX server sockets which
> * were created outside of the newly created Landlock domain (e.g. from within
> * a parent domain or from an unrestricted process). Newly created UNIX
> * servers within the same Landlock domain continue to be accessible. In this
> * regard, %LANDLOCK_ACCESS_FS_RESOLVE_UNIX has the same semantics as the
> * ``LANDLOCK_SCOPE_*`` flags.
> *
> - * If a resolve attempt is denied, the operation returns an ``EACCES`` error,
> - * in line with other filesystem access rights (but different to denials for
> - * abstract UNIX domain sockets).
> + * If a resolution attempt is denied, the operation returns an ``EACCES``
> + * error, in line with other filesystem access rights (but different to
> + * denials for abstract UNIX domain sockets).
> *
> * This access right is available since the ninth version of the Landlock ABI.
> *
> --
> 2.54.0
>
Friendly ping, Mickaël!
This is only a minor change, but keeps the man pages and kernel docs wording in line.
—Günther
^ permalink raw reply
* Re: [PATCH] Documentation: landlock: Document fs.resolve_unix audit blocker
From: Günther Noack @ 2026-06-25 12:31 UTC (permalink / raw)
To: Doehyun Baek
Cc: Mickaël Salaün, Jonathan Corbet, Shuah Khan,
Sebastian Andrzej Siewior, linux-security-module, linux-doc,
linux-kernel
In-Reply-To: <20260625092819.1870049-1-doehyunbaek@gmail.com>
On Thu, Jun 25, 2026 at 09:28:19AM +0000, Doehyun Baek wrote:
> The Landlock audit code can emit fs.resolve_unix as a filesystem blocker
> for pathname UNIX socket resolution denials, but the admin guide's blockers
> list did not mention it.
>
> Add the missing blocker name and ABI version to keep the audit
> documentation in sync with the emitted records.
>
> Fixes: ae97330d1bd6 ("landlock: Control pathname UNIX domain socket resolution by path")
> Signed-off-by: Doehyun Baek <doehyunbaek@gmail.com>
> ---
> Documentation/admin-guide/LSM/landlock.rst | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/admin-guide/LSM/landlock.rst b/Documentation/admin-guide/LSM/landlock.rst
> index 314052bbeb0a..8eb85c9381ff 100644
> --- a/Documentation/admin-guide/LSM/landlock.rst
> +++ b/Documentation/admin-guide/LSM/landlock.rst
> @@ -52,6 +52,7 @@ AUDIT_LANDLOCK_ACCESS
> - fs.refer (ABI 2+)
> - fs.truncate (ABI 3+)
> - fs.ioctl_dev (ABI 5+)
> + - fs.resolve_unix (ABI 9+)
>
> **net.*** - Network access rights (ABI 4+):
> - net.bind_tcp - TCP port binding was denied
>
> base-commit: ab9de95c9cf952332ab79453b4b5d1bfca8e514f
> --
> 2.43.0
>
Thanks, good catch!
Reviewed-by: Günther Noack <gnoack@google.com>
^ permalink raw reply
* Re: [PATCH v18 3/8] rust: implement `ForeignOwnable` for `Owned`
From: Gary Guo @ 2026-06-25 13:29 UTC (permalink / raw)
To: Andreas Hindborg, Danilo Krummrich, Lorenzo Stoakes,
Vlastimil Babka, Liam R. Howlett, Uladzislau Rezki, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Alice Ryhl, Trevor Gross, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Lyude Paul,
Greg Kroah-Hartman, Arve Hjønnevåg, Todd Kjos,
Christian Brauner, Carlos Llamas, Rafael J. Wysocki, Dave Ertman,
Ira Weiny, Leon Romanovsky, Paul Moore, Serge Hallyn,
David Airlie, Simona Vetter, Alexander Viro, Jan Kara,
Igor Korotin, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Bjorn Helgaas, Krzysztof Wilczyński, Pavel Tikhomirov,
Michal Wilczynski
Cc: Philipp Stanner, rust-for-linux, linux-kernel, linux-mm,
driver-core, linux-block, linux-security-module, dri-devel,
linux-fsdevel, linux-pm, linux-pci, linux-pwm
In-Reply-To: <20260625-unique-ref-v18-3-4e06b5896d47@kernel.org>
On Thu Jun 25, 2026 at 11:15 AM BST, Andreas Hindborg wrote:
> Implement `ForeignOwnable` for `Owned<T>`. This allows use of `Owned<T>` in
> places such as the `XArray`.
>
> Note that `T` does not need to implement `ForeignOwnable` for `Owned<T>` to
> implement `ForeignOwnable`.
>
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
> ---
> rust/kernel/owned.rs | 53 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 53 insertions(+)
>
> diff --git a/rust/kernel/owned.rs b/rust/kernel/owned.rs
> index 7fe9ec3e55126..9c92d4a83cc1b 100644
> --- a/rust/kernel/owned.rs
> +++ b/rust/kernel/owned.rs
> @@ -15,6 +15,8 @@
> ptr::NonNull, //
> };
>
> +use kernel::types::ForeignOwnable;
> +
> /// Types that specify their own way of performing allocation and destruction. Typically, this trait
> /// is implemented on types from the C side.
> ///
> @@ -186,3 +188,54 @@ fn drop(&mut self) {
> unsafe { T::release(self.ptr) };
> }
> }
> +
> +// SAFETY: We derive the pointer to `T` from a valid `T`, so the returned
> +// pointer satisfy alignment requirements of `T`.
> +unsafe impl<T: Ownable> ForeignOwnable for Owned<T> {
> + const FOREIGN_ALIGN: usize = core::mem::align_of::<T>();
> +
> + type Borrowed<'a>
> + = &'a T
> + where
> + Self: 'a;
> + type BorrowedMut<'a>
> + = Pin<&'a mut T>
> + where
> + Self: 'a;
> +
> + #[inline]
> + fn into_foreign(self) -> *mut kernel::ffi::c_void {
> + let ptr = self.ptr.as_ptr().cast();
> + core::mem::forget(self);
> + ptr
I think the pattern in `into_raw` is better:
ManuallyDrop::new(self).ptr.as_ptr().cast()
Or perhaps this can just use `Self::into_raw(self).as_ptr().cast()`.
> + }
> +
> + #[inline]
> + unsafe fn from_foreign(ptr: *mut kernel::ffi::c_void) -> Self {
> + // INVARIANT: By the function safety contract, `ptr` was returned by `into_foreign`, which
> + // gave up exclusive ownership of a valid, pinned `T`; we retake that ownership here.
> + Self {
> + // SAFETY: By function safety contract, `ptr` came from
> + // `into_foreign` and cannot be null.
> + ptr: unsafe { NonNull::new_unchecked(ptr.cast()) },
> + }
> + }
Same here, could be using `Self::from_raw`.
However, the current code looks correct to me regardless, so:
Reviewed-by: Gary Guo <gary@garyguo.net>
Best,
Gary
> +
> + #[inline]
> + unsafe fn borrow<'a>(ptr: *mut kernel::ffi::c_void) -> Self::Borrowed<'a> {
> + // SAFETY: By function safety requirements, `ptr` is valid for use as a
> + // reference for `'a`.
> + unsafe { &*ptr.cast() }
> + }
> +
> + #[inline]
> + unsafe fn borrow_mut<'a>(ptr: *mut kernel::ffi::c_void) -> Self::BorrowedMut<'a> {
> + // SAFETY: By function safety requirements, `ptr` is valid for use as a
> + // unique reference for `'a`.
> + let inner = unsafe { &mut *ptr.cast() };
> +
> + // SAFETY: We never move out of inner, and we do not hand out mutable
> + // references when `T: !Unpin`.
> + unsafe { Pin::new_unchecked(inner) }
> + }
> +}
^ permalink raw reply
* Re: [PATCH v18 4/8] rust: page: convert to `Ownable`
From: Gary Guo @ 2026-06-25 13:32 UTC (permalink / raw)
To: Andreas Hindborg, Danilo Krummrich, Lorenzo Stoakes,
Vlastimil Babka, Liam R. Howlett, Uladzislau Rezki, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Alice Ryhl, Trevor Gross, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Lyude Paul,
Greg Kroah-Hartman, Arve Hjønnevåg, Todd Kjos,
Christian Brauner, Carlos Llamas, Rafael J. Wysocki, Dave Ertman,
Ira Weiny, Leon Romanovsky, Paul Moore, Serge Hallyn,
David Airlie, Simona Vetter, Alexander Viro, Jan Kara,
Igor Korotin, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Bjorn Helgaas, Krzysztof Wilczyński, Pavel Tikhomirov,
Michal Wilczynski
Cc: Philipp Stanner, rust-for-linux, linux-kernel, linux-mm,
driver-core, linux-block, linux-security-module, dri-devel,
linux-fsdevel, linux-pm, linux-pci, linux-pwm, Asahi Lina
In-Reply-To: <20260625-unique-ref-v18-4-4e06b5896d47@kernel.org>
On Thu Jun 25, 2026 at 11:15 AM BST, Andreas Hindborg wrote:
> From: Asahi Lina <lina@asahilina.net>
>
> This allows Page references to be returned as borrowed references,
> without necessarily owning the struct page.
>
> Remove `BorrowedPage` and update users to use `Owned<Page>`.
>
> Signed-off-by: Asahi Lina <lina@asahilina.net>
> [ Andreas: Fix formatting and add a safety comment, update users. ]
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Nice to see `BorrowedPage` going away.
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> drivers/android/binder/page_range.rs | 10 +--
> rust/kernel/alloc/allocator.rs | 19 +++---
> rust/kernel/alloc/allocator/iter.rs | 6 +-
> rust/kernel/page.rs | 122 +++++++++--------------------------
> 4 files changed, 46 insertions(+), 111 deletions(-)
^ permalink raw reply
* Re: [PATCH v3 1/2] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
From: Christian Brauner @ 2026-06-25 14:23 UTC (permalink / raw)
To: Paul Moore
Cc: David Windsor, viro, brauner, jack, ast, daniel, john.fastabend,
andrii, eddyz87, memxor, martin.lau, song, yonghong.song, jolsa,
emil, kpsingh, mattbobrowski, jmorris, serge, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg,
stephen.smalley.work, omosnace, casey, shuah, linux-kernel,
linux-fsdevel, bpf, linux-security-module, linux-integrity,
selinux, linux-kselftest
In-Reply-To: <75d39fd9847cca915d704235264ab474@paul-moore.com>
On 2026-06-23 20:12:32-04:00, Paul Moore wrote:
> On Jun 18, 2026 David Windsor <dwindsor@gmail.com> wrote:
>
> > Add bpf_init_inode_xattr() kfunc for BPF LSM programs to atomically set
> > xattrs via the inode_init_security hook using lsm_get_xattr_slot().
> >
> > The inode_init_security hook previously took the xattr array and count
> > as two separate output parameters (struct xattr *xattrs, int
> > *xattr_count), which BPF programs cannot write to. Pass the xattr state
> > as a single context object (struct xattr_ctx) instead, and have
> > bpf_init_inode_xattr() take that context directly. Update the existing
> > in-tree callers of inode_init_security to take and forward the new
> > xattr_ctx.
> >
> > A previous attempt [1] required a kmalloc string output protocol for
> > the xattr name. Since commit 6bcdfd2cac55 ("security: Allow all LSMs to
> > provide xattrs for inode_init_security hook") [2], the xattr name is no
> > longer allocated; it is a static constant.
> >
> > Because we rely on the hook-specific ctx layout, the kfunc is
> > restricted to lsm/inode_init_security. Restrict the xattr names that
> > may be set via this kfunc to the bpf.* namespace.
> >
> > Link: https://kernsec.org/pipermail/linux-security-module-archive/2022-October/034878.html [1]
> > Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6bcdfd2cac55 [2]
> > Suggested-by: Song Liu <song@kernel.org>
> > Signed-off-by: David Windsor <dwindsor@gmail.com>
> > ---
> > fs/bpf_fs_kfuncs.c | 106 +++++++++++++++++++++++++++++-
> > include/linux/bpf.h | 1 +
> > include/linux/bpf_lsm.h | 3 +
> > include/linux/evm.h | 9 +--
> > include/linux/lsm_hook_defs.h | 4 +-
> > include/linux/lsm_hooks.h | 16 ++---
> > include/linux/security.h | 5 ++
> > kernel/bpf/bpf_lsm.c | 10 +++
> > kernel/bpf/trampoline.c | 3 +
> > security/bpf/hooks.c | 1 +
> > security/integrity/evm/evm_main.c | 8 ++-
> > security/security.c | 7 +-
> > security/selinux/hooks.c | 4 +-
> > security/smack/smack_lsm.c | 27 ++++----
> > 14 files changed, 166 insertions(+), 38 deletions(-)
>
> I have a few specific comments below, inline with the patch, but I wanted
> to make some general comments too.
>
> The kfunc additions really don't belong in the VFS kfunc file, please
> create a LSM kfunc file (call it security/bpf_lsm_kfuncs.c) and add the
> kfunc code to this new file.
We expose a bunch of VFS heavy operations for various security modules
and this is really not different. For xattrs we have it all centralized
in the VFS and in general all VFS related bpf kfuncs should continue
living there and be registered there. Anything that's just bpf infra
specific can go to security/bpf/kfuncs.c instead. But anyway, it's a bpf
specific helper so it's the bpf maintainer's call.
^ permalink raw reply
* Re: [PATCH] LSM: check if lsmprop_to_secctx call is supported by LSM
From: Sebastian Bockholt @ 2026-06-25 15:24 UTC (permalink / raw)
To: Casey Schaufler, Sebastian Bockholt, linux-security-module
Cc: serge, jmorris, paul
In-Reply-To: <3a6208ae-ed80-4859-8c41-76010fad3f0d@schaufler-ca.com>
On Wed Jun 24, 2026 at 9:36 PM CEST, Casey Schaufler wrote:
> On 6/24/2026 10:44 AM, Sebastian Bockholt wrote:
>> On Fri Jun 19, 2026 at 7:44 PM CEST, Casey Schaufler wrote:
>>> If you want to help with the multiple LSM support, there's still
>>> plenty of work to do. Let me know.
>> This is my first time trying to contribute to the kernel. If this is the wrong
>> mailing list or wrong format to discuss this, please tell me directly.
>
> You have come to the right place.
>
Thank you and very much appreciated.
>>> If the BPF LSM (the BPF LSM infrastructure, not the eBPF programs)
>>> is going to support security contexts you need to mark it
>>> LSM_FLAGS_EXCLUSIVE.
>> [...]
>>
>>> Until then your choices are:
>>>
>>> - Make the BPF LSM exclusive
>>> - Do not use any of the security context or secid based hooks
>>>
>> I am not trying to load any BPF myself but I am debugging issues when using
>> auditd and apparmor in parallel.
>
> Where does BPF appear in your LSM order?
>
> % cat /sys/kernel/security/lsm
>
> If bpf shows up ahead of apparmor you will see this problem.
>
You were right:
% cat /sys/kernel/security/lsm
capability,landlock,yama,bpf,apparmor
Reordering the LSM order to capability,landlock,yama,apparmor,bpf fixed
the issue.
Thank you
>> As soon as I try to load audit rules from
>> userspace our logs get spammed with "error in audit_log_subj_ctx" messages.
>> According to my analysis, the function call chain leading to the bug is:
>>
>> 1. audit_log_subj_ctx defined in kernel/audit.c
>> // the only LSM enabled is apparmor -> audit_subj_secctx_cnt == 1
>> // confirmed using bpftrace
>> if (audit_subj_secctx_cnt < 2) {
>> error = security_lsmprop_to_secctx(prop, &ctx, LSM_ID_UNDEF);
>> if (error < 0) {
>> if (error != -EINVAL)
>> goto error_path; // produces err msgs in logs
>> return 0;
>> }
>> audit_log_format(ab, " subj=%s", ctx.context);
>> security_release_secctx(&ctx);
>> }
>>
>> 2. security_lsmprop_to_secctx defined in security/security.c
>> // lsm_for_each_hook iterates over all registered LSMs
>> // lsm_id == LSM_ID_UNDEF -> the first lsmprop_to_secctx hook is used
>> // tracing the following probes using bpftrace
>> // kretprobe:apparmor_lsmprop_to_secctx
>> // kretprobe:selinux_lsmprop_to_secctx
>> // kretprobe:smack_lsmprop_to_secctx
>> // kretprobe:bpf_lsm_lsmprop_to_secctx
>> // kretprobe:security_lsmprop_to_scctx
>> // bpf_lsm_lsmprop_to_secctx hook is executed and returns -EOPNOTSUPP
>> lsm_for_each_hook(scall, lsmprop_to_secctx) {
>> if (lsmid != LSM_ID_UNDEF && lsmid != scall->hl->lsmid->id)
>> continue;
>> return scall->hl->hook.lsmprop_to_secctx(prop, cp);
>> }
>>
>> 3. bpf_lsm_lsmprop_to_secctx
>> is defined through #include <linux/lsm_hook_defs.h> and returns
>> -EOPNOTSUPP default. The return value is propagated up the call stack
>> up to security_lsmprop_to_secctx and then to audit_log_subj_ctx.
>> audit_log_subj_ctx checks for error return values and prints the
>> audit_panic "error in audit_log_subj_ctx"
>>
>> My patch could check for any errors or lsmprop_to_secctx but since some might
>> be useful to check by another function in the call stack, i decided to only
>> check if the hook is supported by the LSM.
^ permalink raw reply
* Re: [PATCH v3 1/2] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
From: Paul Moore @ 2026-06-25 16:06 UTC (permalink / raw)
To: Christian Brauner
Cc: David Windsor, viro, jack, ast, daniel, john.fastabend, andrii,
eddyz87, memxor, martin.lau, song, yonghong.song, jolsa, emil,
kpsingh, mattbobrowski, jmorris, serge, zohar, roberto.sassu,
dmitry.kasatkin, eric.snowberg, stephen.smalley.work, omosnace,
casey, shuah, linux-kernel, linux-fsdevel, bpf,
linux-security-module, linux-integrity, selinux, linux-kselftest
In-Reply-To: <20260625-schnabel-rennmaschine-parieren-bcb352c3cf59@brauner>
On Thu, Jun 25, 2026 at 10:23 AM Christian Brauner <brauner@kernel.org> wrote:
> On 2026-06-23 20:12:32-04:00, Paul Moore wrote:
> > On Jun 18, 2026 David Windsor <dwindsor@gmail.com> wrote:
> >
> > > Add bpf_init_inode_xattr() kfunc for BPF LSM programs to atomically set
> > > xattrs via the inode_init_security hook using lsm_get_xattr_slot().
> > >
> > > The inode_init_security hook previously took the xattr array and count
> > > as two separate output parameters (struct xattr *xattrs, int
> > > *xattr_count), which BPF programs cannot write to. Pass the xattr state
> > > as a single context object (struct xattr_ctx) instead, and have
> > > bpf_init_inode_xattr() take that context directly. Update the existing
> > > in-tree callers of inode_init_security to take and forward the new
> > > xattr_ctx.
> > >
> > > A previous attempt [1] required a kmalloc string output protocol for
> > > the xattr name. Since commit 6bcdfd2cac55 ("security: Allow all LSMs to
> > > provide xattrs for inode_init_security hook") [2], the xattr name is no
> > > longer allocated; it is a static constant.
> > >
> > > Because we rely on the hook-specific ctx layout, the kfunc is
> > > restricted to lsm/inode_init_security. Restrict the xattr names that
> > > may be set via this kfunc to the bpf.* namespace.
> > >
> > > Link: https://kernsec.org/pipermail/linux-security-module-archive/2022-October/034878.html [1]
> > > Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6bcdfd2cac55 [2]
> > > Suggested-by: Song Liu <song@kernel.org>
> > > Signed-off-by: David Windsor <dwindsor@gmail.com>
> > > ---
> > > fs/bpf_fs_kfuncs.c | 106 +++++++++++++++++++++++++++++-
> > > include/linux/bpf.h | 1 +
> > > include/linux/bpf_lsm.h | 3 +
> > > include/linux/evm.h | 9 +--
> > > include/linux/lsm_hook_defs.h | 4 +-
> > > include/linux/lsm_hooks.h | 16 ++---
> > > include/linux/security.h | 5 ++
> > > kernel/bpf/bpf_lsm.c | 10 +++
> > > kernel/bpf/trampoline.c | 3 +
> > > security/bpf/hooks.c | 1 +
> > > security/integrity/evm/evm_main.c | 8 ++-
> > > security/security.c | 7 +-
> > > security/selinux/hooks.c | 4 +-
> > > security/smack/smack_lsm.c | 27 ++++----
> > > 14 files changed, 166 insertions(+), 38 deletions(-)
> >
> > I have a few specific comments below, inline with the patch, but I wanted
> > to make some general comments too.
> >
> > The kfunc additions really don't belong in the VFS kfunc file, please
> > create a LSM kfunc file (call it security/bpf_lsm_kfuncs.c) and add the
> > kfunc code to this new file.
>
> We expose a bunch of VFS heavy operations for various security modules
> and this is really not different. For xattrs we have it all centralized
> in the VFS and in general all VFS related bpf kfuncs should continue
> living there and be registered there.
This is really LSM specific code dealing with more LSM bits than
anything else, it belongs in security/bpf_lsm_kfuncs.c.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v3 1/2] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
From: Alexei Starovoitov @ 2026-06-25 19:58 UTC (permalink / raw)
To: Christian Brauner
Cc: Paul Moore, David Windsor, Alexander Viro, Jan Kara,
Alexei Starovoitov, Daniel Borkmann, John Fastabend,
Andrii Nakryiko, Eduard, Kumar Kartikeya Dwivedi,
Martin KaFai Lau, Song Liu, Yonghong Song, Jiri Olsa,
Emil Tsalapatis, KP Singh, Matt Bobrowski, James Morris,
Serge E . Hallyn, Mimi Zohar, Roberto Sassu, dmitry.kasatkin,
eric.snowberg, Stephen Smalley, Ondrej Mosnacek, Casey Schaufler,
Shuah Khan, LKML, Linux-Fsdevel, bpf, LSM List, linux-integrity,
selinux, open list:KERNEL SELFTEST FRAMEWORK
In-Reply-To: <20260625-schnabel-rennmaschine-parieren-bcb352c3cf59@brauner>
On Thu, Jun 25, 2026 at 7:23 AM Christian Brauner <brauner@kernel.org> wrote:
>
> On 2026-06-23 20:12:32-04:00, Paul Moore wrote:
> > On Jun 18, 2026 David Windsor <dwindsor@gmail.com> wrote:
> >
> > > Add bpf_init_inode_xattr() kfunc for BPF LSM programs to atomically set
> > > xattrs via the inode_init_security hook using lsm_get_xattr_slot().
> > >
> > > The inode_init_security hook previously took the xattr array and count
> > > as two separate output parameters (struct xattr *xattrs, int
> > > *xattr_count), which BPF programs cannot write to. Pass the xattr state
> > > as a single context object (struct xattr_ctx) instead, and have
> > > bpf_init_inode_xattr() take that context directly. Update the existing
> > > in-tree callers of inode_init_security to take and forward the new
> > > xattr_ctx.
> > >
> > > A previous attempt [1] required a kmalloc string output protocol for
> > > the xattr name. Since commit 6bcdfd2cac55 ("security: Allow all LSMs to
> > > provide xattrs for inode_init_security hook") [2], the xattr name is no
> > > longer allocated; it is a static constant.
> > >
> > > Because we rely on the hook-specific ctx layout, the kfunc is
> > > restricted to lsm/inode_init_security. Restrict the xattr names that
> > > may be set via this kfunc to the bpf.* namespace.
> > >
> > > Link: https://kernsec.org/pipermail/linux-security-module-archive/2022-October/034878.html [1]
> > > Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6bcdfd2cac55 [2]
> > > Suggested-by: Song Liu <song@kernel.org>
> > > Signed-off-by: David Windsor <dwindsor@gmail.com>
> > > ---
> > > fs/bpf_fs_kfuncs.c | 106 +++++++++++++++++++++++++++++-
> > > include/linux/bpf.h | 1 +
> > > include/linux/bpf_lsm.h | 3 +
> > > include/linux/evm.h | 9 +--
> > > include/linux/lsm_hook_defs.h | 4 +-
> > > include/linux/lsm_hooks.h | 16 ++---
> > > include/linux/security.h | 5 ++
> > > kernel/bpf/bpf_lsm.c | 10 +++
> > > kernel/bpf/trampoline.c | 3 +
> > > security/bpf/hooks.c | 1 +
> > > security/integrity/evm/evm_main.c | 8 ++-
> > > security/security.c | 7 +-
> > > security/selinux/hooks.c | 4 +-
> > > security/smack/smack_lsm.c | 27 ++++----
> > > 14 files changed, 166 insertions(+), 38 deletions(-)
> >
> > I have a few specific comments below, inline with the patch, but I wanted
> > to make some general comments too.
> >
> > The kfunc additions really don't belong in the VFS kfunc file, please
> > create a LSM kfunc file (call it security/bpf_lsm_kfuncs.c) and add the
> > kfunc code to this new file.
>
> We expose a bunch of VFS heavy operations for various security modules
> and this is really not different. For xattrs we have it all centralized
> in the VFS and in general all VFS related bpf kfuncs should continue
> living there and be registered there. Anything that's just bpf infra
> specific can go to security/bpf/kfuncs.c instead. But anyway, it's a bpf
> specific helper so it's the bpf maintainer's call.
Completely agree. This is vfs related kfunc and has to be
in fs/bpf_fs_kfuncs.c to make sure vfs maintainers review it now
and all future changes to it.
^ permalink raw reply
* Re: [PATCH bpf-next v2 1/5] bpf: Verify signed loader metadata at load time
From: Daniel Borkmann @ 2026-06-25 20:37 UTC (permalink / raw)
To: Paul Moore
Cc: ast, kpsingh, James.Bottomley, bboscaccy, memxor, torvalds, bpf,
linux-security-module
In-Reply-To: <CAHC9VhTF6_VaSm0uOjW1eV05CvsaaL+2jimVuPTXHeLGEQcMPg@mail.gmail.com>
On 6/24/26 8:42 PM, Paul Moore wrote:
> On Wed, Jun 24, 2026 at 11:37 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
>> On 6/24/26 5:12 PM, Paul Moore wrote:
>>> On Wed, Jun 24, 2026 at 10:03 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
>> [...]
>>>> include/linux/bpf_verifier.h | 1 +
>>>> kernel/bpf/syscall.c | 76 +---------------
>>>> kernel/bpf/verifier.c | 163 ++++++++++++++++++++++++++++++++++-
>>>> 3 files changed, 165 insertions(+), 75 deletions(-)
>>>
>>> ...
>>>
>>>> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
>>>> index b44106c8ea75..026b61d78bdb 100644
>>>> --- a/kernel/bpf/syscall.c
>>>> +++ b/kernel/bpf/syscall.c
>>>> @@ -3189,10 +3121,6 @@ static int bpf_prog_load(union bpf_attr *attr, bpfptr_t uattr, struct bpf_log_at
>>>> if (err < 0)
>>>> goto free_prog;
>>>>
>>>> - err = security_bpf_prog_load(prog, attr, token, uattr.is_kernel);
>>>> - if (err)
>>>> - goto free_prog;
>>>> -
>>>> /* run eBPF verifier */
>>>> err = bpf_check(&prog, attr, uattr, attr_log);
>>>> if (err < 0)
>>>
>>> We must preserve the existing location of the call into the
>>> security_bpf_prog_load() hook as some users rely on this hook being
>>> called *before* the verifier runs.
>>
>> Keep in mind that the verifier /at this point/ of the new location did
>> _not_ verify anything. So there is no heavy-duty work happening yet at
>> security_bpf_prog_load. The work that is done before security_bpf_prog_load
>> is basically setting up the env, initializing the verifier log, and doing
>> the process_fd_array which is resolving the map/BTF objects. But it did
>> not walk any instructions etc, so semantics of the security_bpf_prog_load
>> hook did not change from a user PoV.
>
> There is still a reasonable amount of work between the existing and
> new call sites, and the existing location outside of bpf_check()
> offers an additional robustness benefit that future verifier changes
> are less likely to impact the hook. If I'm completely honest, I also
> need to consider the events of the past year and a half; I'm now much
> less inclined to support LSM hook changes in the BPF subsystem because
> I'm very concerned about our ability to revert/modify those changes in
> the future if needed. That doesn't mean I won't support LSM hook
> changes in BPF, but such changes are going to need to have a *very*
> strong advantage from a LSM perspective to offset the risk associated
> with the current BPF subsystem.
From where you sit with regards to LSMs that is a natural stance towards
all kernel code, but coming back to the LSM hook, to me this is way too
excessive that we should add *yet another* LSM hook. So, just for loading
a *single* BPF program we would then need to pass through *four* layers of
LSM hooks:
1) security_bpf (cmd=PROG_LOAD): for gating various bpf subcmds
2) security_bpf_prog_load: historical admission hook (CAP/token,
prog_type, attach point), pre-verification
3) security_bpf_prog_verify_signature: newly asked admission hook,
same role as 2), plus the BPF signature verdict
4) security_bpf_prog: gate handing the prog fd back to userspace,
verification done & signature verified
The use-cases of 2) and 3) conflate. I strongly prefer to just keep a
total of 3 LSM hooks (as-is today): 3) makes 2) incoherent given they
are the /same class/ of hook, that is, access-control admission on the
load and split only by _what_ they can see. Worse, with the split, for
a signed BPF program security_bpf_prog_load 2) admits a program whose
signature has not been checked, so a policy gating at 2) is structurally
unable to express "admit only verified" and every such policy is forced
onto 3) *anyway*. In other words, you don't get two complementary hooks,
but rather, you get one real admission hook aka 3) plus a now-degraded
/legacy/ hook 2) that can't answer the question operators actually want
to ask. So, no, we're not adding yet another LSM hook.
> Based on what I see in this patchset, the security_bpf_prog_load()
> call should remain in the current location. If you need an additional
> hook after the bpf_prog_verify_signature() call I'm happy to work with
> you on that.
See above.
> I also have to bring up the same question I asked back in your v1
> posting: have you discussed this signature approach with Alexei? Your
> patches abandon and remove KP's signature scheme in favor of what is
> effectively Blaise's signature scheme from last fall; Alexei argued
> very strongly against these changes in the past. I'd hate to spend a
> lot more time reviewing and discussing patches that Alexei is simply
> going to NACK once again.
I think last time I already stated that this is not "effectively Blaise's
signature scheme" for couple of reasons: i) we sign over the raw bytes, not
the derived hash anymore, so the hashing is only used in the context to tie
the map to the loader program, but not anymore for the signature. ii) its one
/single scheme/ and not a parallel branch, so the main loader is built upon
the updated signing scheme rather than having this as an option on the side;
in other words, this replaces the in-loader check and there's a single
PKCS#7-over-bytes path, not an 'if (signature_maps_size)' fork; and iii)
given we expose the verification result in the BPF prog, we also don't need
a new LSM hook and can just piggy back on the existing security_bpf_prog
which also has the possibility to still reject late at this point.
From where you started out back then, it was the stance that while the
original KP approach generically addresses all the use cases for loading
BPF related to relocations via the lskel loader, Blaise proposed a parallel
scheme which would only allow static programs (only insns, no maps) which
is 1% of use cases it covers for the BPF ecosystem and users are stuck on
figuring out which approach they need to go with. So when I took over the
BTF series with the extra kfunc that KP proposed, I was mainly looking at
that series trying to figure out how we can get away without pulling in BTF
complexity for the signed loader and with a compromise that would potentially
satisfy all parties under a unified signature scheme and having the kernel
side (rather than loader side) providing the hard guarantee. So I cannot
directly speak for Alexei/KP, but I think this proposal should satisfy all
parties under one roof. I've build out user space tooling in addition to
test real world BPF program to make sure they work in combination with maps
and BTF under this scheme as well as map-less BPF programs.
>>>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>>>> index 2abc79dbf281..9cd2b62da380 100644
>>>> --- a/kernel/bpf/verifier.c
>>>> +++ b/kernel/bpf/verifier.c
>>>> @@ -19758,11 +19895,28 @@ int bpf_check(struct bpf_prog **prog, union bpf_attr *attr, bpfptr_t uattr,
>>>> ret = bpf_vlog_init(&env->log, attr_log->level, attr_log->ubuf, attr_log->size);
>>>> if (ret)
>>>> goto err_unlock;
>>>> + if (env->check_signature) {
>>>> + ret = bpf_prog_calc_tag(env->prog);
>>>> + if (ret < 0)
>>>> + goto skip_full_check;
>>>> + }
>>>>
>>>> ret = process_fd_array(env, attr, uattr);
>>>> if (ret)
>>>> goto skip_full_check;
>>>>
>>>> + if (env->check_signature) {
>>>> + ret = bpf_prog_verify_signature(env, attr, uattr.is_kernel);
>>>> + if (ret)
>>>> + goto skip_full_check;
>>>> + signed_map_cnt = env->used_map_cnt;
>>>> + }
>>>> +
>>>> + ret = security_bpf_prog_load(env->prog, attr, env->prog->aux->token,
>>>> + uattr.is_kernel);
>>>> + if (ret)
>>>> + goto skip_full_check;
>>>
>>> We can always create a new LSM hook for this call site, e.g.
>>> security_bpf_prog_verify_signature(...).
>>>
>>>> mark_verifier_state_clean(env);
>>>>
>>>> if (IS_ERR(btf_vmlinux)) {
>
^ permalink raw reply
* Re: [PATCH v3 1/2] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
From: Paul Moore @ 2026-06-25 20:40 UTC (permalink / raw)
To: David Windsor
Cc: Alexei Starovoitov, Christian Brauner, Alexander Viro, Jan Kara,
Alexei Starovoitov, Daniel Borkmann, John Fastabend,
Andrii Nakryiko, Eduard, Kumar Kartikeya Dwivedi,
Martin KaFai Lau, Song Liu, Yonghong Song, Jiri Olsa,
Emil Tsalapatis, KP Singh, Matt Bobrowski, James Morris,
Serge E . Hallyn, Mimi Zohar, Roberto Sassu, dmitry.kasatkin,
eric.snowberg, Stephen Smalley, Ondrej Mosnacek, Casey Schaufler,
Shuah Khan, LKML, Linux-Fsdevel, bpf, LSM List, linux-integrity,
selinux, open list:KERNEL SELFTEST FRAMEWORK
In-Reply-To: <CAADnVQKKr5cCYTj8qS7tU-Aeda1iexYUp5aquTjYXMEL656cJQ@mail.gmail.com>
On Thu, Jun 25, 2026 at 3:58 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> On Thu, Jun 25, 2026 at 7:23 AM Christian Brauner <brauner@kernel.org> wrote:
> > On 2026-06-23 20:12:32-04:00, Paul Moore wrote:
> > > On Jun 18, 2026 David Windsor <dwindsor@gmail.com> wrote:
> > >
> > > > Add bpf_init_inode_xattr() kfunc for BPF LSM programs to atomically set
> > > > xattrs via the inode_init_security hook using lsm_get_xattr_slot().
> > > >
> > > > The inode_init_security hook previously took the xattr array and count
> > > > as two separate output parameters (struct xattr *xattrs, int
> > > > *xattr_count), which BPF programs cannot write to. Pass the xattr state
> > > > as a single context object (struct xattr_ctx) instead, and have
> > > > bpf_init_inode_xattr() take that context directly. Update the existing
> > > > in-tree callers of inode_init_security to take and forward the new
> > > > xattr_ctx.
> > > >
> > > > A previous attempt [1] required a kmalloc string output protocol for
> > > > the xattr name. Since commit 6bcdfd2cac55 ("security: Allow all LSMs to
> > > > provide xattrs for inode_init_security hook") [2], the xattr name is no
> > > > longer allocated; it is a static constant.
> > > >
> > > > Because we rely on the hook-specific ctx layout, the kfunc is
> > > > restricted to lsm/inode_init_security. Restrict the xattr names that
> > > > may be set via this kfunc to the bpf.* namespace.
> > > >
> > > > Link: https://kernsec.org/pipermail/linux-security-module-archive/2022-October/034878.html [1]
> > > > Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6bcdfd2cac55 [2]
> > > > Suggested-by: Song Liu <song@kernel.org>
> > > > Signed-off-by: David Windsor <dwindsor@gmail.com>
> > > > ---
> > > > fs/bpf_fs_kfuncs.c | 106 +++++++++++++++++++++++++++++-
> > > > include/linux/bpf.h | 1 +
> > > > include/linux/bpf_lsm.h | 3 +
> > > > include/linux/evm.h | 9 +--
> > > > include/linux/lsm_hook_defs.h | 4 +-
> > > > include/linux/lsm_hooks.h | 16 ++---
> > > > include/linux/security.h | 5 ++
> > > > kernel/bpf/bpf_lsm.c | 10 +++
> > > > kernel/bpf/trampoline.c | 3 +
> > > > security/bpf/hooks.c | 1 +
> > > > security/integrity/evm/evm_main.c | 8 ++-
> > > > security/security.c | 7 +-
> > > > security/selinux/hooks.c | 4 +-
> > > > security/smack/smack_lsm.c | 27 ++++----
> > > > 14 files changed, 166 insertions(+), 38 deletions(-)
> > >
> > > I have a few specific comments below, inline with the patch, but I wanted
> > > to make some general comments too.
> > >
> > > The kfunc additions really don't belong in the VFS kfunc file, please
> > > create a LSM kfunc file (call it security/bpf_lsm_kfuncs.c) and add the
> > > kfunc code to this new file.
> >
> > We expose a bunch of VFS heavy operations for various security modules
> > and this is really not different. For xattrs we have it all centralized
> > in the VFS and in general all VFS related bpf kfuncs should continue
> > living there and be registered there. Anything that's just bpf infra
> > specific can go to security/bpf/kfuncs.c instead. But anyway, it's a bpf
> > specific helper so it's the bpf maintainer's call.
>
> Completely agree. This is vfs related kfunc and has to be
> in fs/bpf_fs_kfuncs.c to make sure vfs maintainers review it now
> and all future changes to it.
*laughs*
Okay, then split out the LSM specific stuff into
security/bpf_lsm_kfuncs.c; all the LSM macros/defines/calls should be
in the LSM kfuncs file.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v18 3/8] rust: implement `ForeignOwnable` for `Owned`
From: Andreas Hindborg @ 2026-06-25 19:47 UTC (permalink / raw)
To: Gary Guo, Danilo Krummrich, Lorenzo Stoakes, Vlastimil Babka,
Liam R. Howlett, Uladzislau Rezki, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Alice Ryhl,
Trevor Gross, Daniel Almeida, Tamir Duberstein, Alexandre Courbot,
Onur Özkan, Lyude Paul, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Rafael J. Wysocki, Dave Ertman, Ira Weiny,
Leon Romanovsky, Paul Moore, Serge Hallyn, David Airlie,
Simona Vetter, Alexander Viro, Jan Kara, Igor Korotin,
Viresh Kumar, Nishanth Menon, Stephen Boyd, Bjorn Helgaas,
Krzysztof Wilczyński, Pavel Tikhomirov, Michal Wilczynski
Cc: Philipp Stanner, rust-for-linux, linux-kernel, linux-mm,
driver-core, linux-block, linux-security-module, dri-devel,
linux-fsdevel, linux-pm, linux-pci, linux-pwm
In-Reply-To: <DJI5ZY2TPFSW.BEKOVZYRSTQZ@garyguo.net>
"Gary Guo" <gary@garyguo.net> writes:
> On Thu Jun 25, 2026 at 11:15 AM BST, Andreas Hindborg wrote:
>> Implement `ForeignOwnable` for `Owned<T>`. This allows use of `Owned<T>` in
>> places such as the `XArray`.
>>
>> Note that `T` does not need to implement `ForeignOwnable` for `Owned<T>` to
>> implement `ForeignOwnable`.
>>
>> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
>> ---
>> rust/kernel/owned.rs | 53 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 53 insertions(+)
>>
>> diff --git a/rust/kernel/owned.rs b/rust/kernel/owned.rs
>> index 7fe9ec3e55126..9c92d4a83cc1b 100644
>> --- a/rust/kernel/owned.rs
>> +++ b/rust/kernel/owned.rs
>> @@ -15,6 +15,8 @@
>> ptr::NonNull, //
>> };
>>
>> +use kernel::types::ForeignOwnable;
>> +
>> /// Types that specify their own way of performing allocation and destruction. Typically, this trait
>> /// is implemented on types from the C side.
>> ///
>> @@ -186,3 +188,54 @@ fn drop(&mut self) {
>> unsafe { T::release(self.ptr) };
>> }
>> }
>> +
>> +// SAFETY: We derive the pointer to `T` from a valid `T`, so the returned
>> +// pointer satisfy alignment requirements of `T`.
>> +unsafe impl<T: Ownable> ForeignOwnable for Owned<T> {
>> + const FOREIGN_ALIGN: usize = core::mem::align_of::<T>();
>> +
>> + type Borrowed<'a>
>> + = &'a T
>> + where
>> + Self: 'a;
>> + type BorrowedMut<'a>
>> + = Pin<&'a mut T>
>> + where
>> + Self: 'a;
>> +
>> + #[inline]
>> + fn into_foreign(self) -> *mut kernel::ffi::c_void {
>> + let ptr = self.ptr.as_ptr().cast();
>> + core::mem::forget(self);
>> + ptr
>
> I think the pattern in `into_raw` is better:
>
> ManuallyDrop::new(self).ptr.as_ptr().cast()
>
> Or perhaps this can just use `Self::into_raw(self).as_ptr().cast()`.
>
>> + }
>> +
>> + #[inline]
>> + unsafe fn from_foreign(ptr: *mut kernel::ffi::c_void) -> Self {
>> + // INVARIANT: By the function safety contract, `ptr` was returned by `into_foreign`, which
>> + // gave up exclusive ownership of a valid, pinned `T`; we retake that ownership here.
>> + Self {
>> + // SAFETY: By function safety contract, `ptr` came from
>> + // `into_foreign` and cannot be null.
>> + ptr: unsafe { NonNull::new_unchecked(ptr.cast()) },
>> + }
>> + }
>
> Same here, could be using `Self::from_raw`.
>
> However, the current code looks correct to me regardless, so:
>
> Reviewed-by: Gary Guo <gary@garyguo.net>
I'll defer to `{into,from}_raw`. Keeping your tag.
Best regards,
Andreas Hindborg
^ permalink raw reply
* Re: [PATCH v3 1/2] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
From: Alexei Starovoitov @ 2026-06-25 20:44 UTC (permalink / raw)
To: Paul Moore
Cc: David Windsor, Christian Brauner, Alexander Viro, Jan Kara,
Alexei Starovoitov, Daniel Borkmann, John Fastabend,
Andrii Nakryiko, Eduard, Kumar Kartikeya Dwivedi,
Martin KaFai Lau, Song Liu, Yonghong Song, Jiri Olsa,
Emil Tsalapatis, KP Singh, Matt Bobrowski, James Morris,
Serge E . Hallyn, Mimi Zohar, Roberto Sassu, dmitry.kasatkin,
eric.snowberg, Stephen Smalley, Ondrej Mosnacek, Casey Schaufler,
Shuah Khan, LKML, Linux-Fsdevel, bpf, LSM List, linux-integrity,
selinux, open list:KERNEL SELFTEST FRAMEWORK
In-Reply-To: <CAHC9VhSXXHGRUmJ4YjQ6uEh6dbq7+h_0TwWiV+W5dUWXCTFcfg@mail.gmail.com>
On Thu, Jun 25, 2026 at 1:40 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Thu, Jun 25, 2026 at 3:58 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> > On Thu, Jun 25, 2026 at 7:23 AM Christian Brauner <brauner@kernel.org> wrote:
> > > On 2026-06-23 20:12:32-04:00, Paul Moore wrote:
> > > > On Jun 18, 2026 David Windsor <dwindsor@gmail.com> wrote:
> > > >
> > > > > Add bpf_init_inode_xattr() kfunc for BPF LSM programs to atomically set
> > > > > xattrs via the inode_init_security hook using lsm_get_xattr_slot().
> > > > >
> > > > > The inode_init_security hook previously took the xattr array and count
> > > > > as two separate output parameters (struct xattr *xattrs, int
> > > > > *xattr_count), which BPF programs cannot write to. Pass the xattr state
> > > > > as a single context object (struct xattr_ctx) instead, and have
> > > > > bpf_init_inode_xattr() take that context directly. Update the existing
> > > > > in-tree callers of inode_init_security to take and forward the new
> > > > > xattr_ctx.
> > > > >
> > > > > A previous attempt [1] required a kmalloc string output protocol for
> > > > > the xattr name. Since commit 6bcdfd2cac55 ("security: Allow all LSMs to
> > > > > provide xattrs for inode_init_security hook") [2], the xattr name is no
> > > > > longer allocated; it is a static constant.
> > > > >
> > > > > Because we rely on the hook-specific ctx layout, the kfunc is
> > > > > restricted to lsm/inode_init_security. Restrict the xattr names that
> > > > > may be set via this kfunc to the bpf.* namespace.
> > > > >
> > > > > Link: https://kernsec.org/pipermail/linux-security-module-archive/2022-October/034878.html [1]
> > > > > Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6bcdfd2cac55 [2]
> > > > > Suggested-by: Song Liu <song@kernel.org>
> > > > > Signed-off-by: David Windsor <dwindsor@gmail.com>
> > > > > ---
> > > > > fs/bpf_fs_kfuncs.c | 106 +++++++++++++++++++++++++++++-
> > > > > include/linux/bpf.h | 1 +
> > > > > include/linux/bpf_lsm.h | 3 +
> > > > > include/linux/evm.h | 9 +--
> > > > > include/linux/lsm_hook_defs.h | 4 +-
> > > > > include/linux/lsm_hooks.h | 16 ++---
> > > > > include/linux/security.h | 5 ++
> > > > > kernel/bpf/bpf_lsm.c | 10 +++
> > > > > kernel/bpf/trampoline.c | 3 +
> > > > > security/bpf/hooks.c | 1 +
> > > > > security/integrity/evm/evm_main.c | 8 ++-
> > > > > security/security.c | 7 +-
> > > > > security/selinux/hooks.c | 4 +-
> > > > > security/smack/smack_lsm.c | 27 ++++----
> > > > > 14 files changed, 166 insertions(+), 38 deletions(-)
> > > >
> > > > I have a few specific comments below, inline with the patch, but I wanted
> > > > to make some general comments too.
> > > >
> > > > The kfunc additions really don't belong in the VFS kfunc file, please
> > > > create a LSM kfunc file (call it security/bpf_lsm_kfuncs.c) and add the
> > > > kfunc code to this new file.
> > >
> > > We expose a bunch of VFS heavy operations for various security modules
> > > and this is really not different. For xattrs we have it all centralized
> > > in the VFS and in general all VFS related bpf kfuncs should continue
> > > living there and be registered there. Anything that's just bpf infra
> > > specific can go to security/bpf/kfuncs.c instead. But anyway, it's a bpf
> > > specific helper so it's the bpf maintainer's call.
> >
> > Completely agree. This is vfs related kfunc and has to be
> > in fs/bpf_fs_kfuncs.c to make sure vfs maintainers review it now
> > and all future changes to it.
>
> *laughs*
>
> Okay, then split out the LSM specific stuff into
> security/bpf_lsm_kfuncs.c; all the LSM macros/defines/calls should be
> in the LSM kfuncs file.
Paul,
I'm sorry, but you didn't demonstrate the level of understanding
of bpf to be trusted to maintain any piece of it.
^ permalink raw reply
* Re: [PATCH v3 1/2] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
From: Paul Moore @ 2026-06-25 20:47 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David Windsor, Christian Brauner, Alexander Viro, Jan Kara,
Alexei Starovoitov, Daniel Borkmann, John Fastabend,
Andrii Nakryiko, Eduard, Kumar Kartikeya Dwivedi,
Martin KaFai Lau, Song Liu, Yonghong Song, Jiri Olsa,
Emil Tsalapatis, KP Singh, Matt Bobrowski, James Morris,
Serge E . Hallyn, Mimi Zohar, Roberto Sassu, dmitry.kasatkin,
eric.snowberg, Stephen Smalley, Ondrej Mosnacek, Casey Schaufler,
Shuah Khan, LKML, Linux-Fsdevel, bpf, LSM List, linux-integrity,
selinux, open list:KERNEL SELFTEST FRAMEWORK
In-Reply-To: <CAADnVQJM15E0PwomdTiz8zvVMGkqs9mTSjYRdPBF6fgE=tsPCQ@mail.gmail.com>
On Thu, Jun 25, 2026 at 4:44 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> On Thu, Jun 25, 2026 at 1:40 PM Paul Moore <paul@paul-moore.com> wrote:
> > On Thu, Jun 25, 2026 at 3:58 PM Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > > On Thu, Jun 25, 2026 at 7:23 AM Christian Brauner <brauner@kernel.org> wrote:
> > > > On 2026-06-23 20:12:32-04:00, Paul Moore wrote:
> > > > > On Jun 18, 2026 David Windsor <dwindsor@gmail.com> wrote:
> > > > >
> > > > > > Add bpf_init_inode_xattr() kfunc for BPF LSM programs to atomically set
> > > > > > xattrs via the inode_init_security hook using lsm_get_xattr_slot().
> > > > > >
> > > > > > The inode_init_security hook previously took the xattr array and count
> > > > > > as two separate output parameters (struct xattr *xattrs, int
> > > > > > *xattr_count), which BPF programs cannot write to. Pass the xattr state
> > > > > > as a single context object (struct xattr_ctx) instead, and have
> > > > > > bpf_init_inode_xattr() take that context directly. Update the existing
> > > > > > in-tree callers of inode_init_security to take and forward the new
> > > > > > xattr_ctx.
> > > > > >
> > > > > > A previous attempt [1] required a kmalloc string output protocol for
> > > > > > the xattr name. Since commit 6bcdfd2cac55 ("security: Allow all LSMs to
> > > > > > provide xattrs for inode_init_security hook") [2], the xattr name is no
> > > > > > longer allocated; it is a static constant.
> > > > > >
> > > > > > Because we rely on the hook-specific ctx layout, the kfunc is
> > > > > > restricted to lsm/inode_init_security. Restrict the xattr names that
> > > > > > may be set via this kfunc to the bpf.* namespace.
> > > > > >
> > > > > > Link: https://kernsec.org/pipermail/linux-security-module-archive/2022-October/034878.html [1]
> > > > > > Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6bcdfd2cac55 [2]
> > > > > > Suggested-by: Song Liu <song@kernel.org>
> > > > > > Signed-off-by: David Windsor <dwindsor@gmail.com>
> > > > > > ---
> > > > > > fs/bpf_fs_kfuncs.c | 106 +++++++++++++++++++++++++++++-
> > > > > > include/linux/bpf.h | 1 +
> > > > > > include/linux/bpf_lsm.h | 3 +
> > > > > > include/linux/evm.h | 9 +--
> > > > > > include/linux/lsm_hook_defs.h | 4 +-
> > > > > > include/linux/lsm_hooks.h | 16 ++---
> > > > > > include/linux/security.h | 5 ++
> > > > > > kernel/bpf/bpf_lsm.c | 10 +++
> > > > > > kernel/bpf/trampoline.c | 3 +
> > > > > > security/bpf/hooks.c | 1 +
> > > > > > security/integrity/evm/evm_main.c | 8 ++-
> > > > > > security/security.c | 7 +-
> > > > > > security/selinux/hooks.c | 4 +-
> > > > > > security/smack/smack_lsm.c | 27 ++++----
> > > > > > 14 files changed, 166 insertions(+), 38 deletions(-)
> > > > >
> > > > > I have a few specific comments below, inline with the patch, but I wanted
> > > > > to make some general comments too.
> > > > >
> > > > > The kfunc additions really don't belong in the VFS kfunc file, please
> > > > > create a LSM kfunc file (call it security/bpf_lsm_kfuncs.c) and add the
> > > > > kfunc code to this new file.
> > > >
> > > > We expose a bunch of VFS heavy operations for various security modules
> > > > and this is really not different. For xattrs we have it all centralized
> > > > in the VFS and in general all VFS related bpf kfuncs should continue
> > > > living there and be registered there. Anything that's just bpf infra
> > > > specific can go to security/bpf/kfuncs.c instead. But anyway, it's a bpf
> > > > specific helper so it's the bpf maintainer's call.
> > >
> > > Completely agree. This is vfs related kfunc and has to be
> > > in fs/bpf_fs_kfuncs.c to make sure vfs maintainers review it now
> > > and all future changes to it.
> >
> > *laughs*
> >
> > Okay, then split out the LSM specific stuff into
> > security/bpf_lsm_kfuncs.c; all the LSM macros/defines/calls should be
> > in the LSM kfuncs file.
>
> Paul,
>
> I'm sorry, but you didn't demonstrate the level of understanding
> of bpf to be trusted to maintain any piece of it.
Alexei,
You haven't demonstrated the understanding or decorum necessary to be
entrusted with any part of the LSM framework.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH bpf-next v2 1/5] bpf: Verify signed loader metadata at load time
From: Paul Moore @ 2026-06-26 0:59 UTC (permalink / raw)
To: Daniel Borkmann
Cc: ast, kpsingh, James.Bottomley, bboscaccy, memxor, torvalds, bpf,
linux-security-module
In-Reply-To: <c4dc3117-ad84-4c94-952a-cf0642cb42e7@iogearbox.net>
On Thu, Jun 25, 2026 at 4:37 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 6/24/26 8:42 PM, Paul Moore wrote:
> > On Wed, Jun 24, 2026 at 11:37 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
> >> On 6/24/26 5:12 PM, Paul Moore wrote:
> >>> On Wed, Jun 24, 2026 at 10:03 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
> >> [...]
> >>>> include/linux/bpf_verifier.h | 1 +
> >>>> kernel/bpf/syscall.c | 76 +---------------
> >>>> kernel/bpf/verifier.c | 163 ++++++++++++++++++++++++++++++++++-
> >>>> 3 files changed, 165 insertions(+), 75 deletions(-)
> >>>
> >>> ...
> >>>
> >>>> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> >>>> index b44106c8ea75..026b61d78bdb 100644
> >>>> --- a/kernel/bpf/syscall.c
> >>>> +++ b/kernel/bpf/syscall.c
> >>>> @@ -3189,10 +3121,6 @@ static int bpf_prog_load(union bpf_attr *attr, bpfptr_t uattr, struct bpf_log_at
> >>>> if (err < 0)
> >>>> goto free_prog;
> >>>>
> >>>> - err = security_bpf_prog_load(prog, attr, token, uattr.is_kernel);
> >>>> - if (err)
> >>>> - goto free_prog;
> >>>> -
> >>>> /* run eBPF verifier */
> >>>> err = bpf_check(&prog, attr, uattr, attr_log);
> >>>> if (err < 0)
> >>>
> >>> We must preserve the existing location of the call into the
> >>> security_bpf_prog_load() hook as some users rely on this hook being
> >>> called *before* the verifier runs.
> >>
> >> Keep in mind that the verifier /at this point/ of the new location did
> >> _not_ verify anything. So there is no heavy-duty work happening yet at
> >> security_bpf_prog_load. The work that is done before security_bpf_prog_load
> >> is basically setting up the env, initializing the verifier log, and doing
> >> the process_fd_array which is resolving the map/BTF objects. But it did
> >> not walk any instructions etc, so semantics of the security_bpf_prog_load
> >> hook did not change from a user PoV.
> >
> > There is still a reasonable amount of work between the existing and
> > new call sites, and the existing location outside of bpf_check()
> > offers an additional robustness benefit that future verifier changes
> > are less likely to impact the hook. If I'm completely honest, I also
> > need to consider the events of the past year and a half; I'm now much
> > less inclined to support LSM hook changes in the BPF subsystem because
> > I'm very concerned about our ability to revert/modify those changes in
> > the future if needed. That doesn't mean I won't support LSM hook
> > changes in BPF, but such changes are going to need to have a *very*
> > strong advantage from a LSM perspective to offset the risk associated
> > with the current BPF subsystem.
>
> From where you sit with regards to LSMs that is a natural stance towards
> all kernel code, but coming back to the LSM hook, to me this is way too
> excessive that we should add *yet another* LSM hook ...
For all the reasons I gave previously, I can't support moving the
existing security_bpf_prog_load() hook at this point in time.
However, unlike Alexei, I am willing to work with you to develop a new
LSM hook to meet your new needs for enforcing signed BPF program
policies via an LSM (BPF or otherwise). If, as you say, you are not
willing to add a new hook, you will need to find a way to make it work
with the existing hooks/placements.
> > I also have to bring up the same question I asked back in your v1
> > posting: have you discussed this signature approach with Alexei? Your
> > patches abandon and remove KP's signature scheme in favor of what is
> > effectively Blaise's signature scheme from last fall; Alexei argued
> > very strongly against these changes in the past. I'd hate to spend a
> > lot more time reviewing and discussing patches that Alexei is simply
> > going to NACK once again.
>
> I think last time I already stated that this is not "effectively Blaise's
> signature scheme" for couple of reasons ...
I already responded to these three points in your last patchset. It
was sent to you directly, as well as to all of the relevant lists (it
was a reply-all), but here is a lore link if you haven't read it:
https://lore.kernel.org/linux-security-module/CAHC9VhQQKNvP1Who0DdUc0EsVYd_JoSneyzOHZ=Q0MP2qQndCw@mail.gmail.com/
> From where you started out back then, it was the stance that while the
> original KP approach generically addresses all the use cases for loading
> BPF related to relocations via the lskel loader, Blaise proposed a parallel
> scheme which would only allow static programs (only insns, no maps) ...
I'm guessing you still haven't looked at Blaise's patchset from last
September. You were CC'd on the original posting, and I sent you a
lore link in our discussion of your v1 patchset, but I guess it's easy
to get busy/distracted and lose track of things. Regardless, here is
another link to Blaise's patchset:
https://lore.kernel.org/linux-security-module/20250929213520.1821223-1-bboscaccy@linux.microsoft.com/
Blaise's patchset proposed a scheme which ran the PKCS7 signature over
the lskel loader and maps in a way *very* similar to what you are
proposing. Blaise's patchset also supported the same key selection as
KP's scheme so user and session signatures were supported without
issue.
> ... So I cannot
> directly speak for Alexei/KP, but I think this proposal should satisfy all
> parties under one roof.
Considering the striking similarities between what you are proposing
and what Blaise proposed last September I *strongly* suggest getting a
basic thumbs-up or thumbs-down from Alexei on this new/old approach
on-list. As you can see from the lore archives, he has vehemently
opposed the approach you are proposing for quite a while. If he has
changed his mind to understand the value in Blaise's approach of
running the PKCS7 signature over both the lskel loader and maps that's
great, but I worry that will not be the case.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH bpf-next v2 1/5] bpf: Verify signed loader metadata at load time
From: Alexei Starovoitov @ 2026-06-26 1:16 UTC (permalink / raw)
To: Paul Moore, Daniel Borkmann
Cc: ast, kpsingh, James.Bottomley, bboscaccy, memxor, torvalds, bpf,
linux-security-module
In-Reply-To: <CAHC9VhRV9jW+dwNf7mW+1zTCsZ1xstBAugWL-TJ-DVNARdzC=Q@mail.gmail.com>
On Thu Jun 25, 2026 at 5:59 PM PDT, Paul Moore wrote:
>
> For all the reasons I gave previously, I can't support moving the
> existing security_bpf_prog_load() hook at this point in time.
Paul,
it's not up to you to approve or deny where security_bpf_prog_load()
is called within bpf subsystem as long as it doesn't affect behavior.
Daniel's patch doesn't change observable state from LSMs pov.
It merely moves the call from syscall.c to verifier.c.
So we're going to proceed.
> I'm guessing you still haven't looked at Blaise's patchset from last
> September.
Blaise approach was Nacked because you guys ignored TOCTOU issue.
I pointed it a year ago before AI was a thing. Then sashiko
pointed it again and the bot explained it in detail. It was again
ignored.
Daniel's v1 sadly had the same issue and sashiko spotted it too.
Hence v2 is moving the location of security_bpf_prog_load().
> on-list. As you can see from the lore archives, he has vehemently
> opposed the approach you are proposing for quite a while.
Exactly, because you kept ignoring TOCTOU issue.
Claiming support for signed bpf that can be easily defeated
is a shameless security scam.
^ permalink raw reply
* [PATCH -next 0/2] Fix call security_backing_file_free second time
From: Cai Xinchen @ 2026-06-26 1:17 UTC (permalink / raw)
To: paul, jmorris, serge, stephen.smalley.work, omosnace, amir73il,
brauner
Cc: linux-security-module, linux-kernel, selinux, caixinchen1,
lujialin4
I found the following path:
alloc_empty_backing-file
init_file(&ff->file, xxx)
-> file_ref_init(&f->f_ref, 1); // only 1
error = init_backing_file
-> security_backing_file_alloc
-> rc = call_int_hook(backing_file_alloc, ...)
if (unlikely(rc))
security_backing_file_free(backing_file); // first call
if (unlikely(error)) {
fput(&ff->file);
-> if (unlikely(file_ref_put(&file->f_ref))) // zero
__fput_deferred(file);
-> ____fput -> __fput -> file_free(file);
-> backing_file_free(backing_file(f));
-> security_backing_file_free(&ff->file); // second call
Cai Xinchen (2):
security: Some cleanup code
security: Fix call security_backing_file_free second time
security/lsm_init.c | 1 -
security/security.c | 5 +----
security/selinux/hooks.c | 1 -
3 files changed, 1 insertion(+), 6 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH -next 1/2] security: Some cleanup code
From: Cai Xinchen @ 2026-06-26 1:17 UTC (permalink / raw)
To: paul, jmorris, serge, stephen.smalley.work, omosnace, amir73il,
brauner
Cc: linux-security-module, linux-kernel, selinux, caixinchen1,
lujialin4
In-Reply-To: <20260626011720.1144213-1-caixinchen1@huawei.com>
Delete an unnecessary blank line and a blobs variable with
duplicate assignment.
Signed-off-by: Cai Xinchen <caixinchen1@huawei.com>
---
security/lsm_init.c | 1 -
security/selinux/hooks.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/security/lsm_init.c b/security/lsm_init.c
index 7c0fd17f1601..d7384866e3a5 100644
--- a/security/lsm_init.c
+++ b/security/lsm_init.c
@@ -290,7 +290,6 @@ static void __init lsm_prepare(struct lsm_info *lsm)
return;
/* Register the LSM blob sizes. */
- blobs = lsm->blobs;
lsm_blob_size_update(&blobs->lbs_cred, &blob_sizes.lbs_cred);
lsm_blob_size_update(&blobs->lbs_file, &blob_sizes.lbs_file);
lsm_blob_size_update(&blobs->lbs_backing_file,
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 1a713d96206f..e5930ebc9e37 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -1748,7 +1748,6 @@ static int bpf_fd_pass(const struct file *file, u32 sid);
static int __file_has_perm(const struct cred *cred, const struct file *file,
u32 av, bool bf_user_file)
-
{
struct common_audit_data ad;
struct inode *inode;
--
2.34.1
^ permalink raw reply related
* [PATCH -next 2/2] security: Fix call security_backing_file_free second time
From: Cai Xinchen @ 2026-06-26 1:17 UTC (permalink / raw)
To: paul, jmorris, serge, stephen.smalley.work, omosnace, amir73il,
brauner
Cc: linux-security-module, linux-kernel, selinux, caixinchen1,
lujialin4
In-Reply-To: <20260626011720.1144213-1-caixinchen1@huawei.com>
I found the following path:
alloc_empty_backing-file
init_file(&ff->file, xxx)
-> file_ref_init(&f->f_ref, 1); // only 1
error = init_backing_file
-> security_backing_file_alloc
-> rc = call_int_hook(backing_file_alloc, ...)
if (unlikely(rc))
security_backing_file_free(backing_file); // first call
if (unlikely(error)) {
fput(&ff->file);
-> if (unlikely(file_ref_put(&file->f_ref))) // zero
__fput_deferred(file);
-> ____fput -> __fput -> file_free(file);
-> backing_file_free(backing_file(f));
-> security_backing_file_free(&ff->file); // second call
Currently, only SELinux has the lsm backing_file_alloc hook, and the
backing_file_free hook is not set. When security_backing_file_free is
called for the first time, the blobs pointer is set to NULL. Therefore,
double free will not occur in the code.
Fixes: 6af36aeb147a ("lsm: add backing_file LSM hooks")
Signed-off-by: Cai Xinchen <caixinchen1@huawei.com>
---
security/security.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/security/security.c b/security/security.c
index 71aea8fdf014..595d3c73253e 100644
--- a/security/security.c
+++ b/security/security.c
@@ -2468,11 +2468,8 @@ int security_backing_file_alloc(struct file *backing_file,
rc = lsm_backing_file_alloc(backing_file);
if (rc)
return rc;
- rc = call_int_hook(backing_file_alloc, backing_file, user_file);
- if (unlikely(rc))
- security_backing_file_free(backing_file);
- return rc;
+ return call_int_hook(backing_file_alloc, backing_file, user_file);
}
/**
--
2.34.1
^ permalink raw reply related
* Re: [PATCH bpf-next v2 1/5] bpf: Verify signed loader metadata at load time
From: Paul Moore @ 2026-06-26 1:38 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Daniel Borkmann, ast, kpsingh, James.Bottomley, bboscaccy, memxor,
torvalds, bpf, linux-security-module
In-Reply-To: <DJIL18C2F40B.39U9WHD43SDBR@gmail.com>
On Thu, Jun 25, 2026 at 9:16 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> On Thu Jun 25, 2026 at 5:59 PM PDT, Paul Moore wrote:
> >
> > For all the reasons I gave previously, I can't support moving the
> > existing security_bpf_prog_load() hook at this point in time.
>
> Paul,
> it's not up to you to approve or deny where security_bpf_prog_load()
> is called within bpf subsystem as long as it doesn't affect behavior.
> Daniel's patch doesn't change observable state from LSMs pov.
> It merely moves the call from syscall.c to verifier.c.
Alexei,
It is my responsibility to speak up and voice my opinion about LSM
hook placement; arguably that is one of the LSM maintainer's larger
responsibilities. Non-trivial work, including several allocations
(which can be quite large in some cases), occurs between the current
placement of security_bpf_prog_load() and Daniel's proposed location.
We must preserve the existing security_bpf_prog_load() call site.
> So we're going to proceed.
Oh goodie, will the fun ever stop?
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH bpf-next v2 1/5] bpf: Verify signed loader metadata at load time
From: Alexei Starovoitov @ 2026-06-26 1:44 UTC (permalink / raw)
To: Paul Moore
Cc: Daniel Borkmann, Alexei Starovoitov, KP Singh, James Bottomley,
Blaise Boscaccy, Kumar Kartikeya Dwivedi, Linus Torvalds, bpf,
LSM List
In-Reply-To: <CAHC9VhQsjW0OJhKYUNEdkt_31oo56aMusDTANDOAQFNQwCpo4A@mail.gmail.com>
On Thu, Jun 25, 2026 at 6:38 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Thu, Jun 25, 2026 at 9:16 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> > On Thu Jun 25, 2026 at 5:59 PM PDT, Paul Moore wrote:
> > >
> > > For all the reasons I gave previously, I can't support moving the
> > > existing security_bpf_prog_load() hook at this point in time.
> >
> > Paul,
> > it's not up to you to approve or deny where security_bpf_prog_load()
> > is called within bpf subsystem as long as it doesn't affect behavior.
> > Daniel's patch doesn't change observable state from LSMs pov.
> > It merely moves the call from syscall.c to verifier.c.
>
> Alexei,
> It is my responsibility to speak up and voice my opinion about LSM
> hook placement; arguably that is one of the LSM maintainer's larger
> responsibilities. Non-trivial work, including several allocations
> (which can be quite large in some cases), occurs between the current
> placement of security_bpf_prog_load() and Daniel's proposed location.
> We must preserve the existing security_bpf_prog_load() call site.
I don't think you read the patch because you're saying nonsense.
^ permalink raw reply
* Re: [PATCH bpf-next v2 1/5] bpf: Verify signed loader metadata at load time
From: Paul Moore @ 2026-06-26 2:01 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Daniel Borkmann, Alexei Starovoitov, KP Singh, James Bottomley,
Blaise Boscaccy, Kumar Kartikeya Dwivedi, Linus Torvalds, bpf,
LSM List
In-Reply-To: <CAADnVQLdDZR+q66XgCgprPnikhE_Zf_LH3XTFh43u_ks62cWRg@mail.gmail.com>
On June 25, 2026 9:44:54 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> On Thu, Jun 25, 2026 at 6:38 PM Paul Moore <paul@paul-moore.com> wrote:
>>
>> On Thu, Jun 25, 2026 at 9:16 PM Alexei Starovoitov
>> <alexei.starovoitov@gmail.com> wrote:
>>> On Thu Jun 25, 2026 at 5:59 PM PDT, Paul Moore wrote:
>>>>
>>>> For all the reasons I gave previously, I can't support moving the
>>>> existing security_bpf_prog_load() hook at this point in time.
>>>
>>> Paul,
>>> it's not up to you to approve or deny where security_bpf_prog_load()
>>> is called within bpf subsystem as long as it doesn't affect behavior.
>>> Daniel's patch doesn't change observable state from LSMs pov.
>>> It merely moves the call from syscall.c to verifier.c.
>>
>> Alexei,
>> It is my responsibility to speak up and voice my opinion about LSM
>> hook placement; arguably that is one of the LSM maintainer's larger
>> responsibilities. Non-trivial work, including several allocations
>> (which can be quite large in some cases), occurs between the current
>> placement of security_bpf_prog_load() and Daniel's proposed location.
>> We must preserve the existing security_bpf_prog_load() call site.
>
> I don't think you read the patch because you're saying nonsense.
I've read the patch, as well as the code between the existing and proposed
call sites that is outside the patch's context, that is the basis of my
comment.
--
paul-moore.com
^ permalink raw reply
* [PATCH v2 stable/linux-6.18.y 0/2] Backport Fix incorrect overlayfs mmap() and mprotect() LSM access controls
From: Cai Xinchen @ 2026-06-26 2:40 UTC (permalink / raw)
To: viro, brauner, jack, miklos, amir73il, paul, jmorris, serge,
stephen.smalley.work, omosnace, gregkh, bboscaccy, caixinchen1
Cc: linux-fsdevel, linux-kernel, linux-unionfs, linux-security-module,
selinux, bpf, lujialin4
v2: Add static to struct kmem_cache *lsm_backing_file_cache; and define
lbs_backing_file as int for keeping the same type as 6.18.
Backport the patch series
"Fix incorrect overlayfs mmap() and mprotect() LSM access controls" [1]
to 6.18 lts
I test selinux-testsuite[2] overlay test, it pass 135 tests.
[1] https://lore.kernel.org/all/20260403030848.731867-5-paul@paul-moore.com/
[2] https://github.com/SELinuxProject/selinux-testsuite
Paul Moore (2):
lsm: add backing_file LSM hooks
selinux: fix overlayfs mmap() and mprotect() access checks
fs/backing-file.c | 17 ++-
fs/file_table.c | 27 +++-
fs/fuse/passthrough.c | 2 +-
fs/internal.h | 3 +-
fs/overlayfs/dir.c | 2 +-
fs/overlayfs/file.c | 2 +-
include/linux/backing-file.h | 4 +-
include/linux/fs.h | 13 ++
include/linux/lsm_audit.h | 2 +-
include/linux/lsm_hook_defs.h | 5 +
include/linux/lsm_hooks.h | 1 +
include/linux/security.h | 22 +++
security/security.c | 109 ++++++++++++++
security/selinux/hooks.c | 242 ++++++++++++++++++++++--------
security/selinux/include/objsec.h | 11 ++
15 files changed, 383 insertions(+), 79 deletions(-)
--
2.18.0.huawei.25
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox