[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YswAqrJrMKIZPpcz@krava>
Date: Mon, 11 Jul 2022 12:51:22 +0200
From: Jiri Olsa <olsajiri@...il.com>
To: Artem Savkov <asavkov@...hat.com>
Cc: Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>, bpf@...r.kernel.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Andrea Arcangeli <aarcange@...hat.com>, dvacek@...hat.com
Subject: Re: [RFC PATCH bpf-next 0/4] bpf_panic() helper
On Mon, Jul 11, 2022 at 10:32:16AM +0200, Artem Savkov wrote:
> eBPF is often used for kernel debugging, and one of the widely used and
> powerful debugging techniques is post-mortem debugging with a full memory dump.
> Triggering a panic at exactly the right moment allows the user to get such a
> dump and thus a better view at the system's state. This patchset adds
> bpf_panic() helper to do exactly that.
FWIW I was asked for such helper some time ago from Daniel Vacek, cc-ed
jirka
>
> I realize that even though there are multiple guards present, a helper like
> this is contrary to BPF being "safe", so this is sent as RFC to have a
> discussion on whether adding destructive capabilities is deemed acceptable.
>
> Artem Savkov (4):
> bpf: add a sysctl to enable destructive bpf helpers
> bpf: add BPF_F_DESTRUCTIVE flag for BPF_PROG_LOAD
> bpf: add bpf_panic() helper
> selftests/bpf: bpf_panic selftest
>
> include/linux/bpf.h | 8 +
> include/uapi/linux/bpf.h | 13 ++
> kernel/bpf/core.c | 1 +
> kernel/bpf/helpers.c | 13 ++
> kernel/bpf/syscall.c | 33 +++-
> kernel/bpf/verifier.c | 7 +
> kernel/trace/bpf_trace.c | 2 +
> tools/include/uapi/linux/bpf.h | 13 ++
> .../selftests/bpf/prog_tests/bpf_panic.c | 144 ++++++++++++++++++
> 9 files changed, 233 insertions(+), 1 deletion(-)
> create mode 100644 tools/testing/selftests/bpf/prog_tests/bpf_panic.c
>
> --
> 2.35.3
>
Powered by blists - more mailing lists