| Message ID | 20180405151645.19130-1-jolsa@kernel.org |
|---|---|
| Headers | show |
| Series | bpf: Add buildid check support | expand |
On Thu, Apr 05, 2018 at 05:16:36PM +0200, Jiri Olsa wrote: > hi, > eBPF programs loaded for kprobes are allowed to read kernel > internal structures. We check the provided kernel version > to ensure that the program is loaded for the proper kernel. > > The problem is that the version check is not enough, because > it only follows the version setup from kernel's Makefile. > However, the internal kernel structures change based on the > .config data, so in practise we have different kernels with > same version. > > The eBPF kprobe program thus then get loaded for different > kernel than it's been built for, get wrong data (silently) > and provide misleading output. > > This patchset implements additional check in eBPF loading code > on provided build ID (from kernel's elf image, .notes section > GNU build ID) to ensure we load the eBPF program on correct > kernel. > > Also available in here (based on bpf-next/master): > https://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git > bpf/checksum > > This patchset consists of several changes: > > - adding CONFIG_BUILDID_H option that instructs the build > to generate uapi header file with build ID data, that > will be included by eBPF program > > - adding CONFIG_BPF_BUILDID_CHECK option and new bpf_attr > field to allow build ID checking when loading the eBPF > program > > - changing libbpf to read and pass build ID to the kernel > > - several small side fixes > > - example perf eBPF code in bpf-samples/bpf-stdout-example.c > to show the build ID support/usage. > > # perf record -vv -e ./bpf-samples/bpf-stdout-example.c kill 2>&1 | grep buildid > libbpf: section(7) buildid, size 21, link 0, flags 3, type=1 > libbpf: kernel buildid of ./bpf-samples/bpf-stdout-example.c is: 6e25edeb408513184e2753bebad25d42314501a0 > > The buildid is provided the same way we provide kernel > version, in a special "buildid" section: > > # cat ./bpf-samples/bpf-stdout-example.c > ... > #include <linux/buildid.h> > > char _buildid[] SEC("buildid") = LINUX_BUILDID_DATA; > ... > > where LINUX_BUILDID_DATA is defined in the generated buildid.h. > > please note it's an RFC ;-) any comments and suggestions are welcome I think this is overkill. We're very heavy users of kprobe+bpf. It's used for lots of different cases and usage is constantly growing, but I haven't seen a single case of : > The eBPF kprobe program thus then get loaded for different > kernel than it's been built for, get wrong data (silently) > and provide misleading output. but I saw plenty of the opposite. People pre-compile the program and hack kernel version when they load, since they know in advance that kprobe+bpf doesn't use any kernel specific things. The existing kernel version check for kprobe+bpf is already annoying to them. This buildid check they can easily bypass the same way. imo the whole thing just adds complexity and doesn't solve anything. Sorry, this is a Nack.
On Thu, Apr 05, 2018 at 06:37:23PM -0700, Alexei Starovoitov wrote: > On Thu, Apr 05, 2018 at 05:16:36PM +0200, Jiri Olsa wrote: > > hi, > > eBPF programs loaded for kprobes are allowed to read kernel > > internal structures. We check the provided kernel version > > to ensure that the program is loaded for the proper kernel. > > > > The problem is that the version check is not enough, because > > it only follows the version setup from kernel's Makefile. > > However, the internal kernel structures change based on the > > .config data, so in practise we have different kernels with > > same version. > > > > The eBPF kprobe program thus then get loaded for different > > kernel than it's been built for, get wrong data (silently) > > and provide misleading output. > > > > This patchset implements additional check in eBPF loading code > > on provided build ID (from kernel's elf image, .notes section > > GNU build ID) to ensure we load the eBPF program on correct > > kernel. > > > > Also available in here (based on bpf-next/master): > > https://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git > > bpf/checksum > > > > This patchset consists of several changes: > > > > - adding CONFIG_BUILDID_H option that instructs the build > > to generate uapi header file with build ID data, that > > will be included by eBPF program > > > > - adding CONFIG_BPF_BUILDID_CHECK option and new bpf_attr > > field to allow build ID checking when loading the eBPF > > program > > > > - changing libbpf to read and pass build ID to the kernel > > > > - several small side fixes > > > > - example perf eBPF code in bpf-samples/bpf-stdout-example.c > > to show the build ID support/usage. > > > > # perf record -vv -e ./bpf-samples/bpf-stdout-example.c kill 2>&1 | grep buildid > > libbpf: section(7) buildid, size 21, link 0, flags 3, type=1 > > libbpf: kernel buildid of ./bpf-samples/bpf-stdout-example.c is: 6e25edeb408513184e2753bebad25d42314501a0 > > > > The buildid is provided the same way we provide kernel > > version, in a special "buildid" section: > > > > # cat ./bpf-samples/bpf-stdout-example.c > > ... > > #include <linux/buildid.h> > > > > char _buildid[] SEC("buildid") = LINUX_BUILDID_DATA; > > ... > > > > where LINUX_BUILDID_DATA is defined in the generated buildid.h. > > > > please note it's an RFC ;-) any comments and suggestions are welcome > > I think this is overkill. > > We're very heavy users of kprobe+bpf. It's used for lots > of different cases and usage is constantly growing, > but I haven't seen a single case of : > > > The eBPF kprobe program thus then get loaded for different > > kernel than it's been built for, get wrong data (silently) > > and provide misleading output. > > but I saw plenty of the opposite. People pre-compile the program > and hack kernel version when they load, since they know in advance > that kprobe+bpf doesn't use any kernel specific things. > The existing kernel version check for kprobe+bpf is already annoying > to them. perhaps verifier could detect this (via bpf_probe_read usage) and disable the version check automaticaly for such program? and in the same way force the version check (or buildid when enabled) once the bpf_probe_read is detected thanks, jirka
hi, eBPF programs loaded for kprobes are allowed to read kernel internal structures. We check the provided kernel version to ensure that the program is loaded for the proper kernel. The problem is that the version check is not enough, because it only follows the version setup from kernel's Makefile. However, the internal kernel structures change based on the .config data, so in practise we have different kernels with same version. The eBPF kprobe program thus then get loaded for different kernel than it's been built for, get wrong data (silently) and provide misleading output. This patchset implements additional check in eBPF loading code on provided build ID (from kernel's elf image, .notes section GNU build ID) to ensure we load the eBPF program on correct kernel. Also available in here (based on bpf-next/master): https://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git bpf/checksum This patchset consists of several changes: - adding CONFIG_BUILDID_H option that instructs the build to generate uapi header file with build ID data, that will be included by eBPF program - adding CONFIG_BPF_BUILDID_CHECK option and new bpf_attr field to allow build ID checking when loading the eBPF program - changing libbpf to read and pass build ID to the kernel - several small side fixes - example perf eBPF code in bpf-samples/bpf-stdout-example.c to show the build ID support/usage. # perf record -vv -e ./bpf-samples/bpf-stdout-example.c kill 2>&1 | grep buildid libbpf: section(7) buildid, size 21, link 0, flags 3, type=1 libbpf: kernel buildid of ./bpf-samples/bpf-stdout-example.c is: 6e25edeb408513184e2753bebad25d42314501a0 The buildid is provided the same way we provide kernel version, in a special "buildid" section: # cat ./bpf-samples/bpf-stdout-example.c ... #include <linux/buildid.h> char _buildid[] SEC("buildid") = LINUX_BUILDID_DATA; ... where LINUX_BUILDID_DATA is defined in the generated buildid.h. please note it's an RFC ;-) any comments and suggestions are welcome thanks, jirka --- Jiri Olsa (9): perf tools: Make read_build_id function public perf tools: Add fetch_kernel_buildid function kbuild: Do not pass arguments to link-vmlinux.sh kbuild: Add filechk2 function bpf: Add CONFIG_BUILDID_H option bpf: Add CONFIG_BPF_BUILDID_CHECK option libbpf: Synchronize uapi bpf.h header libbpf: Add support to attach buildid to program load perf tools: The buildid usage in example eBPF program Makefile | 14 +++++++++++++- include/uapi/linux/bpf.h | 2 ++ init/Kconfig | 12 ++++++++++++ kernel/bpf/syscall.c | 84 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- scripts/Kbuild.include | 24 ++++++++++++++++++++++++ scripts/Makefile | 1 + scripts/extract-buildid.c | 42 ++++++++++++++++++++++++++++++++++++++++++ tools/bpf/bpftool/Makefile | 5 ++++- tools/include/uapi/linux/bpf.h | 3 +++ tools/lib/bpf/bpf.c | 6 ++++-- tools/lib/bpf/bpf.h | 5 +++-- tools/lib/bpf/libbpf.c | 46 ++++++++++++++++++++++++++++++++++++++++------ tools/perf/bpf-samples/bpf-stdout-example.c | 42 ++++++++++++++++++++++++++++++++++++++++++ tools/perf/tests/bpf.c | 9 ++++++++- tools/perf/util/symbol-minimal.c | 50 ++------------------------------------------------ tools/perf/util/util.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ tools/perf/util/util.h | 6 ++++++ 17 files changed, 355 insertions(+), 62 deletions(-) create mode 100644 scripts/extract-buildid.c create mode 100644 tools/perf/bpf-samples/bpf-stdout-example.c