| 2020-02-14 11:00:51 |
Quentin Monnet |
bug |
|
|
added bug |
| 2020-02-14 11:11:53 |
Christian Brauner |
bug |
|
|
added subscriber Christian Brauner |
| 2020-02-14 11:30:06 |
Ubuntu Kernel Bot |
linux (Ubuntu): status |
New |
Incomplete |
|
| 2020-02-14 12:54:01 |
Quentin Monnet |
linux (Ubuntu): status |
Incomplete |
Confirmed |
|
| 2020-02-19 16:07:39 |
Tyler Hicks |
nominated for series |
|
Ubuntu Eoan |
|
| 2020-02-19 16:07:39 |
Tyler Hicks |
bug task added |
|
linux (Ubuntu Eoan) |
|
| 2020-02-19 16:07:39 |
Tyler Hicks |
nominated for series |
|
Ubuntu Disco |
|
| 2020-02-19 16:07:39 |
Tyler Hicks |
bug task added |
|
linux (Ubuntu Disco) |
|
| 2020-02-19 16:07:47 |
Tyler Hicks |
linux (Ubuntu Disco): status |
New |
Triaged |
|
| 2020-02-19 16:07:49 |
Tyler Hicks |
linux (Ubuntu Eoan): status |
New |
Triaged |
|
| 2020-02-19 16:07:52 |
Tyler Hicks |
linux (Ubuntu Disco): importance |
Undecided |
Medium |
|
| 2020-02-19 16:07:53 |
Tyler Hicks |
linux (Ubuntu Eoan): importance |
Undecided |
Medium |
|
| 2020-02-19 16:08:01 |
Tyler Hicks |
linux (Ubuntu): status |
Confirmed |
Invalid |
|
| 2020-02-19 22:25:32 |
Seth Arnold |
bug |
|
|
added subscriber Seth Arnold |
| 2020-02-19 23:06:43 |
Tyler Hicks |
linux (Ubuntu Disco): status |
Triaged |
In Progress |
|
| 2020-02-19 23:06:45 |
Tyler Hicks |
linux (Ubuntu Eoan): status |
Triaged |
In Progress |
|
| 2020-02-19 23:06:49 |
Tyler Hicks |
linux (Ubuntu Disco): assignee |
|
Tyler Hicks (tyhicks) |
|
| 2020-02-19 23:06:51 |
Tyler Hicks |
linux (Ubuntu Eoan): assignee |
|
Tyler Hicks (tyhicks) |
|
| 2020-02-19 23:30:48 |
Tyler Hicks |
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 |
[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"); }
$ 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 |
|
| 2020-02-19 23:36:48 |
Tyler Hicks |
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"); }
$ 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 |
[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 |
|
| 2020-02-21 00:09:02 |
Tyler Hicks |
bug |
|
|
added subscriber Tyler Hicks |
| 2020-03-06 17:48:53 |
Mike McGhee |
bug |
|
|
added subscriber Mike McGhee |
| 2020-03-11 05:07:02 |
Khaled El Mously |
linux (Ubuntu Eoan): status |
In Progress |
Fix Committed |
|
| 2020-03-16 02:28:03 |
Khaled El Mously |
linux (Ubuntu Disco): status |
In Progress |
Fix Committed |
|
| 2020-03-17 17:33:15 |
Ubuntu Kernel Bot |
tags |
|
verification-needed-eoan |
|
| 2020-03-18 09:01:02 |
Quentin Monnet |
tags |
verification-needed-eoan |
verification-done-eoan |
|
| 2020-03-27 16:42:53 |
Stefan Bader |
linux (Ubuntu Eoan): status |
Fix Committed |
Triaged |
|
| 2020-07-02 19:54:31 |
Steve Langasek |
linux (Ubuntu Disco): status |
Fix Committed |
Won't Fix |
|
| 2020-08-18 16:58:22 |
Brian Murray |
linux (Ubuntu Eoan): status |
Triaged |
Won't Fix |
|
