NACK/Cmnt: [SRU][R][PATCH 0/1] append bpf to CONFIG_LSM

[Stefan Bader]

On 04/09/2026 00:34, Matt Bobrowski wrote:
> BugLink: https://bugs.launchpad.net/bugs/2166235
>   
> [Impact]
>   
> Ubuntu builds the BPF LSM (CONFIG_BPF_LSM=y) but does not list bpf in
> CONFIG_LSM, so it is never initialized (from Resolute Raccoon):
>   
>    $ cat /sys/kernel/security/lsm
>    lockdown,capability,landlock,yama,apparmor,ima,evm
>   
> Projects that use the BPF LSM detect its absence and degrade. systemd
> silently skips RestrictFileSystems=, disables systemd-nsresourced's user
> namespace delegation interfaces, and fails PID 1 startup if
> RestrictFileSystemAccess= (newer systemd) is enabled. Tetragon refuses
> TracingPolicy objects that use LSM hooks and directs users to lsm=bpf on
> the kernel command line. KubeArmor falls back to AppArmor with
> documented gaps. Bespoke LSM programs attach without error and never
> run. The lsm= command-line workaround is unavailable wherever the
> command line is fixed before first boot: cloud images, immutable
> deployments, managed Kubernetes nodes.
>   
> bpf was intentionally excluded in LP: #1905975 pending removal of the
> per-hook indirect-call overhead upstream. Commit 417c5643cd67 ("lsm:
> replace indirect LSM hook calls with static calls") removed it in
> 6.12. Upstream has carried bpf in the CONFIG_LSM default since 5.7
> (520b7aa00d8c ("bpf: lsm: Initialize the BPF LSM hooks")), and every
> other major distribution initializes it. Ubuntu is the outlier.
>   
> [Fix]
>   
> Append bpf to CONFIG_LSM in debian.master/config/annotations for all
> architectures, placed after apparmor to match upstream. Config-only; no
> source change.
>   
> [Test Plan]
>   
> On the patched kernel:
>   
>    $ cat /sys/kernel/security/lsm
>    lockdown,capability,landlock,yama,integrity,apparmor,bpf
>    $ dmesg | grep 'LSM support for eBPF'
>    LSM support for eBPF active
>   
> Attach a BPF_PROG_TYPE_LSM program to file_open and open a file: the
> program runs. Note that on the unpatched kernel the same program
> attaches without error and never runs, so attach success is not a
> discriminating check; observing the hook fire is.
>   
> Regression: aa-status shows profiles loaded and enforcing; a confined
> process is denied as before. Booting with
> lsm=landlock,lockdown,yama,integrity,apparmor removes bpf, confirming
> the command-line override still takes precedence.
>   
> [Where problems could occur]
>   
> With bpf enabled each hook site makes a direct call to an empty noinline
> bpf_lsm_<hook> stub when no program is attached; the bpf slot's static
> key is on at boot because the bpf LSM registers a callback on every
> hook. This is the residual cost after commit 417c5643cd67 ("lsm: replace
> indirect LSM hook calls with static calls"). A follow-up to gate that
> key on program attachment was posted with the series (v13 5/5) but has
> not been merged. A small number of hooks were left as function pointers
> in the conversion, and architectures without CONFIG_STATIC_CALL fall
> back to indirect calls.
>   
> The bpf LSM declares a one-pointer inode security blob
> (bpf_lsm_blob_sizes.lbs_inode), allocated per inode regardless of attach
> state. The former task blob was removed upstream in late 2024.
>   
> bpf_inode_storage_free is registered on inode_free_security and runs on
> every inode teardown; it is a pointer check when no storage exists.
>   
> Some LSM hooks behave differently by the presence of any callback,
> independent of its return value. No such behavioural change has been
> identified for Ubuntu's configuration.
>   
> Enabling the LSM widens what CAP_BPF + CAP_MAC_ADMIN holders may do.
> Nothing changes for unprivileged users.
>   
> Ordering and exclusivity: AppArmor is the only LSM in Ubuntu's list
> carrying LSM_FLAG_EXCLUSIVE; bpf, like landlock, lockdown and yama,
> carries no such flag and cannot displace it regardless of position. bpf
> is placed after apparmor, matching upstream, so hooks reach bpf programs
> only for operations AppArmor has already permitted; AppArmor's own
> decisions are unaffected. Systems booting with lsm= are unaffected,
> since that parameter replaces the built-in list. Systems booting with
> security=apparmor will gain bpf, as that parameter only selects among
> exclusive LSMs.
> 
> Matt Bobrowski (1):
>    UBUNTU: [Config] append bpf to CONFIG_LSM
> 
>   debian.master/config/annotations | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 

Rejected for the following reasons:
Cover email and patch are not threaded (checked in the ML archive)

-Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20260904/067562ea/attachment.sig>