Bug#1079567: systemd: Should not raise errors when not (all) BPF features are available

Luca Boccassi bluca at debian.org
Tue Oct 8 21:45:26 BST 2024


Control: tags -1 wontfix
Control: close -1

On Sat, 24 Aug 2024 18:23:00 +0200 Diederik de Haas
<didi.debian at cknow.org> wrote:
> Package: systemd
> Version: 256.5-1
> Severity: normal
> X-Debbugs-Cc: debian-kernel at lists.debian.org
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> I build a custom (arm64) kernel based on Debian's config and in that
I
> disabled debug info, which in turn disabled
``CONFIG_DEBUG_INFO_BTF``.
> 
> Build was successful and I tried it out on my Rock64 and what I
always
> do when testing kernels is check dmesg for errors/warnings etc:
> 
> ```sh
> root at rock64-test:~# dmesg --level 0,1,2
> root at rock64-test:~# dmesg --level 0,1,2,3
> [    9.807992] rockchip-pm-domain ff100000.syscon:power-controller:
failed to get ack on domain 'hevc', val=0x88220
> [   16.014046] systemd[1]: bpf-restrict-fs: Failed to load BPF
object: No such process
> ```
> 
> Former is known (and in the works of being fixed), the latter is new.
> 
> Looking for that error message led me to upstream issue 32968 [1]
which
> led me to the upstream README with the following:
> 
> ```
>         Required for RestrictFileSystems= in service units:
>           CONFIG_BPF
>           CONFIG_BPF_SYSCALL
>           CONFIG_BPF_LSM
>           CONFIG_DEBUG_INFO_BTF
>           CONFIG_LSM="...,bpf" or kernel booted with lsm="...,bpf".
> ```
> 
> I (actually) do have most of those, but not CONFIG_DEBUG_INFO_BTF and
> that appears to be why systemd throws an error.
> 
> Looking further I found another issue [2] which says that using
> ``lockdown=confidentiality`` will also be problematic.
> 
> I think/assume it's great that systemd would use kernel features like
> BPF *if* they're available. But if not, it should not throw an ERROR.
> 
> An informational message is fine and possibly a warning* if it's
really
> important. But it should detect so at *runtime* and not assume what
> happens to be enabled in the (Debian) kernel at a certain point in
time.

Sorry, but not only is an error appropriate here, it is also probably
not enough. It is not a downstream issue anyway, so feel free to raise
it upstream if you want it changed, but this is the wrong place for
such a request.

> I did grep my system for ``bpf-restrict-fs`` to see if I could
disable 
> that feature, but it only found ``libsystemd-core-256.so``.

You need to disable the relevant sanboxing feature(s) in any unit that
enables it.



More information about the Pkg-systemd-maintainers mailing list