[Kernel-packages] [Bug 1863234] Re: Disabling bpf() syscall on kernel lockdown break apps when secure boot is on
Tested kernel 5.3.0-43-generic from -proposed, on eoan with Secure
Boot/Lockdown enabled. Running 'sudo bpftool prog' works and lists BPF
programs loaded on the system, via the bpf() syscall. Same test on
5.3.0-42-generic would fail with -EPERM.
So the fix works well, and we can now use bpf() even with Lockdown,
thanks! I'll update the verification tag. This is definitely an
improvement, although the resolution here will not address Brendan's
concerns for tracing.
** Tags removed: verification-needed-eoan
** Tags added: verification-done-eoan
--
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:
Fix Committed
Status in linux source package in Eoan:
Fix Committed
Bug description:
[Impact]
The bpf(2) system call is completely blocked in Disco and Eoan when
Secure Boot is enabled due to overly restrictive Lockdown policies.
This makes it so that all bpf related tools are not usable on those
releases.
[Test Case]
Set up test BPF programs:
$ cat hello.bt
BEGIN { printf("hello\n"); exit(); }
$ cat kprobe.bt
kprobe:do_nanosleep { printf("task sleeping...\n"); exit(); }
$ cat open.bt
tracepoint:syscalls:sys_enter_openat {
printf("filename: [%s]; flags: [%d]\n",
str(args->filename), args->flags);
}
Disable Secure Boot:
$ sudo mokutil --disable-validation
...
$ sudo reboot
Ensure that hello.bt can run:
$ sudo bpftrace hello.bt
Attaching 1 probe...
hello
Ensure that a BPF program triggered by a kprobe works (run `sleep 1` in
another terminal):
$ sudo bpftrace kprobe.bt
Attaching 1 probe...
task sleeping...
Ensure that a BPF program triggered by a tracepoint can access the filename
and flags of openat(2):
$ sudo bpftrace open.bt
Attaching 1 probe...
filename: [/proc/2317/cmdline]; flags: [0]
filename: [/dev/iio:device1]; flags: [2048]
...
Enable Secure Boot
$ sudo mokutil --enable-validation
...
$ sudo reboot
Ensure that a basic BPF program can run:
$ sudo bpftrace hello.bt
Attaching 1 probe...
hello
Ensure that a BPF program triggered by a kprobe is blocked (kprobes aren't
allowed under Secure Boot):
$ sudo bpftrace kprobe.bt
Attaching 1 probe...
cannot attach kprobe, Operation not permitted
Error attaching probe: 'kprobe:do_nanosleep'
You should see the following kernel message logged:
Lockdown: bpftrace: Use of kprobes is restricted; see man
kernel_lockdown.7
Ensure that a BPF program triggered by a tracepoint can NOT access the
filename and flags of openat(2) (all filenames should be empty and all flags
should be 0):
$ sudo bpftrace open.bt
Attaching 1 probe...
filename: []; flags: [0]
filename: []; flags: [0]
...
You should see the following kernel message logged:
Lockdown: iio-sensor-prox: BPF is restricted; see man
kernel_lockdown.7
[Regression Potential]
Low. This is opening up the use of bpf(2) while under Lockdown. There
should be no new restrictions put in place.
[Original Report]
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 disrto-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/+subscription
[Kernel-packages] [Bug 1774815] Re: Add bpftool to linux-tools-common
** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- 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/1774815 Title: Add bpftool to linux-tools-common Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Committed Status in linux source package in Cosmic: Won't Fix Bug description: bpftool is a debugging and introspection tool actively developed by the BPF kernel community. It's developed as part of the kernel source tree under tools/: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/bpf/bpftool It would be really great and appreciated if Ubuntu folks could package this as part of linux-tools-common. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1774815/+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
[Kernel-packages] [Bug 1863234] Re: Disabling bpf() syscall on kernel lockdown break apps when secure boot is on
Not adding kernel logs but changing to 'Confirmed'. ** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- 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: Confirmed 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
[Kernel-packages] [Bug 1863234] [NEW] Disabling bpf() syscall on kernel lockdown break apps when secure boot is on
Public bug reported: 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 ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- 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: New 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
[Kernel-packages] [Bug 1774815] Re: Add bpftool to linux-tools-common
Sent a patchset to package bpftool in linux-tools/linux-tools-common for bionic, here is the related link: https://lists.ubuntu.com/archives/kernel-team/2019-July/102462.html -- 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/1774815 Title: Add bpftool to linux-tools-common Status in linux package in Ubuntu: Triaged Status in linux source package in Cosmic: Triaged Bug description: bpftool is a debugging and introspection tool actively developed by the BPF kernel community. It's developed as part of the kernel source tree under tools/: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/bpf/bpftool It would be really great and appreciated if Ubuntu folks could package this as part of linux-tools-common. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1774815/+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
