NACK: [SRU][R/S/unstable][PATCH v2 1/1] UBUNTU: [Config] append bpf to CONFIG_LSM
Matt Bobrowski
matt at bobrowski.net
Tue Sep 8 02:09:42 UTC 2026
On Mon, Sep 07, 2026 at 12:17:07PM +0100, Andrei Gherzan wrote:
> On 26/09/07 12:02PM, Matt Bobrowski wrote:
> > BugLink: https://bugs.launchpad.net/bugs/2166235
> >
> > Ubuntu kernels are built with CONFIG_BPF_LSM=y but omit bpf from
> > CONFIG_LSM, so the BPF LSM is compiled in and never initialized.
> > Projects that use the BPF LSM detect its absence and degrade: systemd
> > skips RestrictFileSystems=, disables systemd-nsresourced's user
> > namespace delegation, and fails PID 1 startup if
> > RestrictFileSystemAccess= is enabled; Tetragon refuses LSM-hook
> > policies; KubeArmor falls back to AppArmor; bespoke BPF_PROG_TYPE_LSM
> > programs attach without error and are never invoked.
> >
> > When CONFIG_BPF_LSM was enabled (LP: #1905975), bpf was deliberately
> > left out of CONFIG_LSM because activating it registered an empty
> > callback on every LSM hook, each costing an indirect, retpoline-
> > mitigated call. That bug records the intent to activate the LSM once
> > upstream removed the overhead. It did in 6.12 with commit 417c5643cd67
> > ("lsm: replace indirect LSM hook calls with static calls"), which
> > converts hook dispatch to static calls. The cost that motivated the
> > omission no longer exists.
> >
> > Upstream security/Kconfig has listed bpf in every CONFIG_LSM default
> > since 5.7, via commit 520b7aa00d8c ("bpf: lsm: Initialize the BPF LSM
> > hooks"). RHEL, Fedora, SUSE, Debian, Arch Oracle UEK, and any other
> > major distribution all initialize it by default. This brings Ubuntu into
> > line with the upstream default. bpf is placed after apparmor, matching
> > upstream; it carries no LSM_FLAG_EXCLUSIVE, so AppArmor remains the
> > exclusive LSM and its decisions are unaffected. Systems booting with
> > lsm= are unaffected, as that parameter replaces the built-in list.
> >
> > Signed-off-by: Matt Bobrowski <matt at bobrowski.net>
> > ---
> > debian.master/config/annotations | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/debian.master/config/annotations b/debian.master/config/annotations
> > index 702fca42e937..e9f8f34d6ffa 100644
> > --- a/debian.master/config/annotations
> > +++ b/debian.master/config/annotations
> > @@ -7507,7 +7507,7 @@ CONFIG_LRU_CACHE policy<{'amd64': 'm', 'arm64': '
> > CONFIG_LRU_GEN_STATS policy<{'amd64': 'n', 'arm64': 'n', 'ppc64el': 'n', 'riscv64': 'n', 's390x': 'n'}>
> > CONFIG_LRU_GEN_WALKS_MMU policy<{'amd64': 'y', 'arm64': 'y'}>
> > CONFIG_LSI_ET1011C_PHY policy<{'amd64': 'm', 'arm64': 'm', 'armhf': 'm', 'ppc64el': 'm', 'riscv64': 'm', 's390x': 'm'}>
> > -CONFIG_LSM policy<{'amd64': '"landlock,lockdown,yama,integrity,apparmor"', 'arm64': '"landlock,lockdown,yama,integrity,apparmor"', 'armhf': '"landlock,lockdown,yama,integrity,apparmor"', 'ppc64el': '"landlock,lockdown,yama,integrity,apparmor"', 'riscv64': '"landlock,lockdown,yama,integrity,apparmor"', 's390x': '"landlock,lockdown,yama,integrity,apparmor"'}>
> > +CONFIG_LSM policy<{'amd64': 'landlock,lockdown,yama,integrity,apparmor,bpf', 'arm64': 'landlock,lockdown,yama,integrity,apparmor,bpf', 'armhf': 'landlock,lockdown,yama,integrity,apparmor,bpf', 'ppc64el': 'landlock,lockdown,yama,integrity,apparmor,bpf', 'riscv64': 'landlock,lockdown,yama,integrity,apparmor,bpf', 's390x': 'landlock,lockdown,yama,integrity,apparmor,bpf'}>
>
> This change drops the embedded double-quote characters. Wouldn't this make the
> config-check tooling trip? Checking annotations.py I can't see how without the
> quotes the tool would satisfy the Kconfig requirement for quoting string types.
Yes, you're absolutely right, those double quotation marks were
accidentally dropped. That's because I didn't wrap the value passed to
--write in single quotes at the time. Sending out a v3 of this patch
series now.
> > CONFIG_LSM_MMAP_MIN_ADDR policy<{'amd64': '0', 'arm64': '0', 'armhf': '0', 'ppc64el': '0', 'riscv64': '0', 's390x': '0'}>
> > CONFIG_LS_EXTIRQ policy<{'arm64': 'y'}>
> > CONFIG_LS_SCFG_MSI policy<{'arm64': 'y'}>
>
> --
> Andrei Gherzan
> gpg: rsa4096/D4D94F67AD0E9640
More information about the kernel-team
mailing list