Hi Quentin - Thanks for the bug report! I do think that relaxing the
eBPF restrictions in Eoan and Disco would be acceptable for Secure Boot
purposes.
** Also affects: linux (Ubuntu Eoan)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Disco)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Disco)
Status: New => Triaged
** Changed in: linux (Ubuntu Eoan)
Status: New => Triaged
** Changed in: linux (Ubuntu Disco)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Eoan)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu)
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1863234
Title:
Disabling bpf() syscall on kernel lockdown break apps when secure boot
is on
Status in linux package in Ubuntu:
Invalid
Status in linux source package in Disco:
Triaged
Status in linux source package in Eoan:
Triaged
Bug description:
In disco and eoan, lockdown is automatically enforced when secure boot
is on [0]. Because lockdown was not in the mailine kernel at the time,
some disto-specific patches were added to the kernel, including one
that drastically restricts BPF usage by completely disabling the use
of the `bpf()` system call when lockdown is on [1].
A consequence of that decision is that no application relying on eBPF
can run on 19.04/19.10, unless secure boot / lockdown is disabled. For
example, Cilium (cilium.io) strongly relies on BPF programs to
implement its datapath and securing network connectivity between
containers. Other applications like Suricata or Sysdig also rely on
BPF to some extent. None of which will work by default on a EFI
machine with secure boot activated.
If I understand correctly, kernel 5.4 (to be used in focal) will have
a different, lighter restricton (comming from mainline Linux kernel)
[2], so `bpf()` for networking use cases should mostly work on 20.04.
Is my understanding correct? If so, could this patch be backported to
19.10 (and 19.04, if still supported) instead of completely disabling
the syscall on lockdown?
Links:
[0]
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/disco/commit/?id=d0db99473fc3bb8a5d03f99ed454ac7ca5e7d517
[1]
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/disco/commit/?id=2a68c65abae66d28e2acb3245cb156ae2ea6eb1d
[2]
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/commit/?id=9d1f8be5cf42b497a3bddf1d523f2bb142e9318c
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1863234/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
