| Message ID | 20220711083220.2175036-4-asavkov@redhat.com (mailing list archive) |
|---|---|
| State | RFC |
| Delegated to: | BPF |
| Headers | show |
| Series | bpf_panic() helper | expand |
| Context | Check | Description |
|---|---|---|
| bpf/vmtest-bpf-next-PR | fail | merge-conflict |
| netdev/tree_selection | success | Clearly marked for bpf-next, async |
| netdev/apply | fail | Patch does not apply to bpf-next |
On Mon, Jul 11, 2022 at 10:32:19AM +0200, Artem Savkov wrote: SNIP > diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h > index 4423874b5da4..e2e2c4de44ee 100644 > --- a/tools/include/uapi/linux/bpf.h > +++ b/tools/include/uapi/linux/bpf.h > @@ -3927,6 +3927,12 @@ union bpf_attr { > * Return > * The 64 bit jiffies > * > + * void bpf_panic(const char *msg) > + * Description > + * Make the kernel panic immediately > + * Return > + * void > + * > * long bpf_read_branch_records(struct bpf_perf_event_data *ctx, void *buf, u32 size, u64 flags) > * Description > * For an eBPF program attached to a perf event, retrieve the > @@ -5452,6 +5458,7 @@ union bpf_attr { > FN(tcp_send_ack), \ > FN(send_signal_thread), \ > FN(jiffies64), \ > + FN(panic), \ > FN(read_branch_records), \ > FN(get_ns_current_pid_tgid), \ > FN(xdp_output), \ new helper needs to be added at the end of the list jirka
On Mon, Jul 11, 2022 at 1:32 AM Artem Savkov <asavkov@redhat.com> wrote: > > Add a helper that will make the kernel panic immediately with specified > message. Using this helper requires kernel.destructive_bpf_enabled sysctl > to be enabled, BPF_F_DESTRUCTIVE flag to be supplied on program load as > well as CAP_SYS_BOOT capabilities. > > Signed-off-by: Artem Savkov <asavkov@redhat.com> > --- > include/linux/bpf.h | 1 + > include/uapi/linux/bpf.h | 7 +++++++ > kernel/bpf/core.c | 1 + > kernel/bpf/helpers.c | 13 +++++++++++++ > kernel/bpf/verifier.c | 7 +++++++ > kernel/trace/bpf_trace.c | 2 ++ > tools/include/uapi/linux/bpf.h | 7 +++++++ > 7 files changed, 38 insertions(+) > > diff --git a/include/linux/bpf.h b/include/linux/bpf.h > index 43c008e3587a..77c20ba9ca8e 100644 > --- a/include/linux/bpf.h > +++ b/include/linux/bpf.h > @@ -2339,6 +2339,7 @@ extern const struct bpf_func_proto bpf_strtol_proto; > extern const struct bpf_func_proto bpf_strtoul_proto; > extern const struct bpf_func_proto bpf_tcp_sock_proto; > extern const struct bpf_func_proto bpf_jiffies64_proto; > +extern const struct bpf_func_proto bpf_panic_proto; > extern const struct bpf_func_proto bpf_get_ns_current_pid_tgid_proto; > extern const struct bpf_func_proto bpf_event_output_data_proto; > extern const struct bpf_func_proto bpf_ringbuf_output_proto; > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h > index 4423874b5da4..e2e2c4de44ee 100644 > --- a/include/uapi/linux/bpf.h > +++ b/include/uapi/linux/bpf.h > @@ -3927,6 +3927,12 @@ union bpf_attr { > * Return > * The 64 bit jiffies > * > + * void bpf_panic(const char *msg) > + * Description > + * Make the kernel panic immediately > + * Return > + * void > + * > * long bpf_read_branch_records(struct bpf_perf_event_data *ctx, void *buf, u32 size, u64 flags) > * Description > * For an eBPF program attached to a perf event, retrieve the > @@ -5452,6 +5458,7 @@ union bpf_attr { > FN(tcp_send_ack), \ > FN(send_signal_thread), \ > FN(jiffies64), \ > + FN(panic), \ > FN(read_branch_records), \ > FN(get_ns_current_pid_tgid), \ > FN(xdp_output), \ > diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c > index b5ffebcce6cc..0f333a0e85a5 100644 > --- a/kernel/bpf/core.c > +++ b/kernel/bpf/core.c > @@ -2649,6 +2649,7 @@ const struct bpf_func_proto bpf_map_lookup_percpu_elem_proto __weak; > const struct bpf_func_proto bpf_spin_lock_proto __weak; > const struct bpf_func_proto bpf_spin_unlock_proto __weak; > const struct bpf_func_proto bpf_jiffies64_proto __weak; > +const struct bpf_func_proto bpf_panic_proto __weak; > > const struct bpf_func_proto bpf_get_prandom_u32_proto __weak; > const struct bpf_func_proto bpf_get_smp_processor_id_proto __weak; > diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c > index a1c84d256f83..5cb90208a264 100644 > --- a/kernel/bpf/helpers.c > +++ b/kernel/bpf/helpers.c > @@ -374,6 +374,19 @@ const struct bpf_func_proto bpf_jiffies64_proto = { > .ret_type = RET_INTEGER, > }; > > +BPF_CALL_1(bpf_panic, const char *, msg) > +{ > + panic(msg); I think we should also check capable(CAP_SYS_BOOT) && destructive_ebpf_enabled() here. Or at least, destructive_ebpf_enabled(). Otherwise, we may trigger panic after the sysctl is disabled. In general, I don't think sysctl is a good API, as it is global, and the user can easily forget to turn it back off. If possible, I would rather avoid adding new BPF related sysctls. Thanks, Song > + return 0; > +} > + > +const struct bpf_func_proto bpf_panic_proto = { > + .func = bpf_panic, > + .gpl_only = false, > + .ret_type = RET_VOID, > + .arg1_type = ARG_PTR_TO_CONST_STR, > +}; > + > #ifdef CONFIG_CGROUPS > BPF_CALL_0(bpf_get_current_cgroup_id) > { > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > index 2859901ffbe3..f49c026917c5 100644 > --- a/kernel/bpf/verifier.c > +++ b/kernel/bpf/verifier.c > @@ -7285,6 +7285,13 @@ static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn > reg_type_str(env, regs[BPF_REG_1].type)); > return -EACCES; > } > + break; > + case BPF_FUNC_panic: > + struct bpf_prog_aux *aux = env->prog->aux; > + if (!aux->destructive) { > + verbose(env, "bpf_panic() calls require BPF_F_DESTRUCTIVE flag\n"); > + return -EACCES; > + } > } > > if (err) > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c > index 4be976cf7d63..3ee888507795 100644 > --- a/kernel/trace/bpf_trace.c > +++ b/kernel/trace/bpf_trace.c > @@ -1304,6 +1304,8 @@ bpf_tracing_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog) > return &bpf_find_vma_proto; > case BPF_FUNC_trace_vprintk: > return bpf_get_trace_vprintk_proto(); > + case BPF_FUNC_panic: > + return capable(CAP_SYS_BOOT) && destructive_ebpf_enabled() ? &bpf_panic_proto : NULL; > default: > return bpf_base_func_proto(func_id); > } > diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h > index 4423874b5da4..e2e2c4de44ee 100644 > --- a/tools/include/uapi/linux/bpf.h > +++ b/tools/include/uapi/linux/bpf.h > @@ -3927,6 +3927,12 @@ union bpf_attr { > * Return > * The 64 bit jiffies > * > + * void bpf_panic(const char *msg) > + * Description > + * Make the kernel panic immediately > + * Return > + * void > + * > * long bpf_read_branch_records(struct bpf_perf_event_data *ctx, void *buf, u32 size, u64 flags) > * Description > * For an eBPF program attached to a perf event, retrieve the > @@ -5452,6 +5458,7 @@ union bpf_attr { > FN(tcp_send_ack), \ > FN(send_signal_thread), \ > FN(jiffies64), \ > + FN(panic), \ > FN(read_branch_records), \ > FN(get_ns_current_pid_tgid), \ > FN(xdp_output), \ > -- > 2.35.3 >
On Tue, Jul 12, 2022 at 10:53 AM Song Liu <song@kernel.org> wrote: > > > > > +BPF_CALL_1(bpf_panic, const char *, msg) > > +{ > > + panic(msg); > > I think we should also check > > capable(CAP_SYS_BOOT) && destructive_ebpf_enabled() > > here. Or at least, destructive_ebpf_enabled(). Otherwise, we > may trigger panic after the sysctl is disabled. > > In general, I don't think sysctl is a good API, as it is global, and > the user can easily forget to turn it back off. If possible, I would > rather avoid adding new BPF related sysctls. +1. New syscal isn't warranted here. Just CAP_SYS_BOOT would be enough here. Also full blown panic() seems unnecessary. If the motivation is to get a memory dump then crash_kexec() helper would be more suitable. If the goal is to reboot the system then the wrapper of sys_reboot() is better. Unfortunately the cover letter lacks these details. Why this destructive action cannot be delegated to user space? btw, we should avoid adding new uapi helpers in most cases. Ideally all of them should be added as new kfunc-s, because they're unstable and we can rip them out later if our judgement call turns out to be problematic for whatever reason.
On Tue, Jul 12, 2022 at 11:08:54AM -0700, Alexei Starovoitov wrote: > On Tue, Jul 12, 2022 at 10:53 AM Song Liu <song@kernel.org> wrote: > > > > > > > > +BPF_CALL_1(bpf_panic, const char *, msg) > > > +{ > > > + panic(msg); > > > > I think we should also check > > > > capable(CAP_SYS_BOOT) && destructive_ebpf_enabled() > > > > here. Or at least, destructive_ebpf_enabled(). Otherwise, we > > may trigger panic after the sysctl is disabled. > > > > In general, I don't think sysctl is a good API, as it is global, and > > the user can easily forget to turn it back off. If possible, I would > > rather avoid adding new BPF related sysctls. > > +1. New syscal isn't warranted here. > Just CAP_SYS_BOOT would be enough here. Point taken, I'll remove sysctl knob in any further versions. > Also full blown panic() seems unnecessary. > If the motivation is to get a memory dump then crash_kexec() helper > would be more suitable. > If the goal is to reboot the system then the wrapper of sys_reboot() > is better. > Unfortunately the cover letter lacks these details. The main goal is to get the memory dump, so crash_kexec() should be enough. However panic() is a bit more versatile and it's consequences are configurable to some extent. Are there any downsides to using it? > Why this destructive action cannot be delegated to user space? Going through userspace adds delays and makes it impossible to hit "exactly the right moment" thus making it unusable in most cases. I'll add this to the cover letter. > btw, we should avoid adding new uapi helpers in most cases. > Ideally all of them should be added as new kfunc-s, because they're > unstable and we can rip them out later if our judgement call > turns out to be problematic for whatever reason. Ok, I'll look into doing it this way.
On Wed, Jul 13, 2022 at 6:31 AM Artem Savkov <asavkov@redhat.com> wrote: > > On Tue, Jul 12, 2022 at 11:08:54AM -0700, Alexei Starovoitov wrote: > > On Tue, Jul 12, 2022 at 10:53 AM Song Liu <song@kernel.org> wrote: > > > > > > > > > > > +BPF_CALL_1(bpf_panic, const char *, msg) > > > > +{ > > > > + panic(msg); > > > > > > I think we should also check > > > > > > capable(CAP_SYS_BOOT) && destructive_ebpf_enabled() > > > > > > here. Or at least, destructive_ebpf_enabled(). Otherwise, we > > > may trigger panic after the sysctl is disabled. > > > > > > In general, I don't think sysctl is a good API, as it is global, and > > > the user can easily forget to turn it back off. If possible, I would > > > rather avoid adding new BPF related sysctls. > > > > +1. New syscal isn't warranted here. > > Just CAP_SYS_BOOT would be enough here. > > Point taken, I'll remove sysctl knob in any further versions. > > > Also full blown panic() seems unnecessary. > > If the motivation is to get a memory dump then crash_kexec() helper > > would be more suitable. > > If the goal is to reboot the system then the wrapper of sys_reboot() > > is better. > > Unfortunately the cover letter lacks these details. > > The main goal is to get the memory dump, so crash_kexec() should be enough. > However panic() is a bit more versatile and it's consequences are configurable > to some extent. Are there any downsides to using it? versatile? In what sense? That it does a lot more than kexec? That's a disadvantage. We should provide bpf with minimal building blocks and let bpf program decide what to do. If dmesg (that is part of panic) is useful it should be its own kfunc. If halt is necessary -> separate kfunc as well. reboot -> another kfunc. Also panic() is not guaranteed to do kexec and just panic is not what you stated is the goal of the helper. > > > Why this destructive action cannot be delegated to user space? > > Going through userspace adds delays and makes it impossible to hit "exactly > the right moment" thus making it unusable in most cases. What would be an example of that? kexec is not instant either. > I'll add this to the cover letter. > > > btw, we should avoid adding new uapi helpers in most cases. > > Ideally all of them should be added as new kfunc-s, because they're > > unstable and we can rip them out later if our judgement call > > turns out to be problematic for whatever reason. > > Ok, I'll look into doing it this way. > > -- > Regards, > Artem >
On Wed, Jul 13, 2022 at 03:20:22PM -0700, Alexei Starovoitov wrote: > On Wed, Jul 13, 2022 at 6:31 AM Artem Savkov <asavkov@redhat.com> wrote: > > > > On Tue, Jul 12, 2022 at 11:08:54AM -0700, Alexei Starovoitov wrote: > > > On Tue, Jul 12, 2022 at 10:53 AM Song Liu <song@kernel.org> wrote: > > > > > > > > > > > > > > +BPF_CALL_1(bpf_panic, const char *, msg) > > > > > +{ > > > > > + panic(msg); > > > > > > > > I think we should also check > > > > > > > > capable(CAP_SYS_BOOT) && destructive_ebpf_enabled() > > > > > > > > here. Or at least, destructive_ebpf_enabled(). Otherwise, we > > > > may trigger panic after the sysctl is disabled. > > > > > > > > In general, I don't think sysctl is a good API, as it is global, and > > > > the user can easily forget to turn it back off. If possible, I would > > > > rather avoid adding new BPF related sysctls. > > > > > > +1. New syscal isn't warranted here. > > > Just CAP_SYS_BOOT would be enough here. > > > > Point taken, I'll remove sysctl knob in any further versions. > > > > > Also full blown panic() seems unnecessary. > > > If the motivation is to get a memory dump then crash_kexec() helper > > > would be more suitable. > > > If the goal is to reboot the system then the wrapper of sys_reboot() > > > is better. > > > Unfortunately the cover letter lacks these details. > > > > The main goal is to get the memory dump, so crash_kexec() should be enough. > > However panic() is a bit more versatile and it's consequences are configurable > > to some extent. Are there any downsides to using it? > > versatile? In what sense? That it does a lot more than kexec? > That's a disadvantage. > We should provide bpf with minimal building blocks and let > bpf program decide what to do. > If dmesg (that is part of panic) is useful it should be its > own kfunc. > If halt is necessary -> separate kfunc as well. > reboot -> another kfunc. > > Also panic() is not guaranteed to do kexec and just > panic is not what you stated is the goal of the helper. Alright, if the aim is to provide the smallest building blocks then crash_kexec() is a better choice. > > > > > Why this destructive action cannot be delegated to user space? > > > > Going through userspace adds delays and makes it impossible to hit "exactly > > the right moment" thus making it unusable in most cases. > > What would be an example of that? > kexec is not instant either. With kexec at least the thread it got called in is in a proper state. I guess it is possible to achieve this by signalling userspace to do kexec/panic and then block the thread somehow but that won't work in a single-cpu case. Or am I missing something?
On Fri, Jul 15, 2022 at 5:52 AM Artem Savkov <asavkov@redhat.com> wrote: > > On Wed, Jul 13, 2022 at 03:20:22PM -0700, Alexei Starovoitov wrote: > > On Wed, Jul 13, 2022 at 6:31 AM Artem Savkov <asavkov@redhat.com> wrote: > > > > > > On Tue, Jul 12, 2022 at 11:08:54AM -0700, Alexei Starovoitov wrote: > > > > On Tue, Jul 12, 2022 at 10:53 AM Song Liu <song@kernel.org> wrote: > > > > > > > > > > > > > > > > > +BPF_CALL_1(bpf_panic, const char *, msg) > > > > > > +{ > > > > > > + panic(msg); > > > > > > > > > > I think we should also check > > > > > > > > > > capable(CAP_SYS_BOOT) && destructive_ebpf_enabled() > > > > > > > > > > here. Or at least, destructive_ebpf_enabled(). Otherwise, we > > > > > may trigger panic after the sysctl is disabled. > > > > > > > > > > In general, I don't think sysctl is a good API, as it is global, and > > > > > the user can easily forget to turn it back off. If possible, I would > > > > > rather avoid adding new BPF related sysctls. > > > > > > > > +1. New syscal isn't warranted here. > > > > Just CAP_SYS_BOOT would be enough here. > > > > > > Point taken, I'll remove sysctl knob in any further versions. > > > > > > > Also full blown panic() seems unnecessary. > > > > If the motivation is to get a memory dump then crash_kexec() helper > > > > would be more suitable. > > > > If the goal is to reboot the system then the wrapper of sys_reboot() > > > > is better. > > > > Unfortunately the cover letter lacks these details. > > > > > > The main goal is to get the memory dump, so crash_kexec() should be enough. > > > However panic() is a bit more versatile and it's consequences are configurable > > > to some extent. Are there any downsides to using it? > > > > versatile? In what sense? That it does a lot more than kexec? > > That's a disadvantage. > > We should provide bpf with minimal building blocks and let > > bpf program decide what to do. > > If dmesg (that is part of panic) is useful it should be its > > own kfunc. > > If halt is necessary -> separate kfunc as well. > > reboot -> another kfunc. > > > > Also panic() is not guaranteed to do kexec and just > > panic is not what you stated is the goal of the helper. > > Alright, if the aim is to provide the smallest building blocks then > crash_kexec() is a better choice. > > > > > > > > Why this destructive action cannot be delegated to user space? > > > > > > Going through userspace adds delays and makes it impossible to hit "exactly > > > the right moment" thus making it unusable in most cases. > > > > What would be an example of that? > > kexec is not instant either. > > With kexec at least the thread it got called in is in a proper state. I > guess it is possible to achieve this by signalling userspace to do > kexec/panic and then block the thread somehow but that won't work in a > single-cpu case. Or am I missing something? Something like this. We can extend bpf_send_signal to send a signal to pid 1 or another user agent. It's still not clear to me why you want that memory dump.
diff --git a/include/linux/bpf.h b/include/linux/bpf.h index 43c008e3587a..77c20ba9ca8e 100644 --- a/include/linux/bpf.h +++ b/include/linux/bpf.h @@ -2339,6 +2339,7 @@ extern const struct bpf_func_proto bpf_strtol_proto; extern const struct bpf_func_proto bpf_strtoul_proto; extern const struct bpf_func_proto bpf_tcp_sock_proto; extern const struct bpf_func_proto bpf_jiffies64_proto; +extern const struct bpf_func_proto bpf_panic_proto; extern const struct bpf_func_proto bpf_get_ns_current_pid_tgid_proto; extern const struct bpf_func_proto bpf_event_output_data_proto; extern const struct bpf_func_proto bpf_ringbuf_output_proto; diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h index 4423874b5da4..e2e2c4de44ee 100644 --- a/include/uapi/linux/bpf.h +++ b/include/uapi/linux/bpf.h @@ -3927,6 +3927,12 @@ union bpf_attr { * Return * The 64 bit jiffies * + * void bpf_panic(const char *msg) + * Description + * Make the kernel panic immediately + * Return + * void + * * long bpf_read_branch_records(struct bpf_perf_event_data *ctx, void *buf, u32 size, u64 flags) * Description * For an eBPF program attached to a perf event, retrieve the @@ -5452,6 +5458,7 @@ union bpf_attr { FN(tcp_send_ack), \ FN(send_signal_thread), \ FN(jiffies64), \ + FN(panic), \ FN(read_branch_records), \ FN(get_ns_current_pid_tgid), \ FN(xdp_output), \ diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c index b5ffebcce6cc..0f333a0e85a5 100644 --- a/kernel/bpf/core.c +++ b/kernel/bpf/core.c @@ -2649,6 +2649,7 @@ const struct bpf_func_proto bpf_map_lookup_percpu_elem_proto __weak; const struct bpf_func_proto bpf_spin_lock_proto __weak; const struct bpf_func_proto bpf_spin_unlock_proto __weak; const struct bpf_func_proto bpf_jiffies64_proto __weak; +const struct bpf_func_proto bpf_panic_proto __weak; const struct bpf_func_proto bpf_get_prandom_u32_proto __weak; const struct bpf_func_proto bpf_get_smp_processor_id_proto __weak; diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c index a1c84d256f83..5cb90208a264 100644 --- a/kernel/bpf/helpers.c +++ b/kernel/bpf/helpers.c @@ -374,6 +374,19 @@ const struct bpf_func_proto bpf_jiffies64_proto = { .ret_type = RET_INTEGER, }; +BPF_CALL_1(bpf_panic, const char *, msg) +{ + panic(msg); + return 0; +} + +const struct bpf_func_proto bpf_panic_proto = { + .func = bpf_panic, + .gpl_only = false, + .ret_type = RET_VOID, + .arg1_type = ARG_PTR_TO_CONST_STR, +}; + #ifdef CONFIG_CGROUPS BPF_CALL_0(bpf_get_current_cgroup_id) { diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 2859901ffbe3..f49c026917c5 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -7285,6 +7285,13 @@ static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn reg_type_str(env, regs[BPF_REG_1].type)); return -EACCES; } + break; + case BPF_FUNC_panic: + struct bpf_prog_aux *aux = env->prog->aux; + if (!aux->destructive) { + verbose(env, "bpf_panic() calls require BPF_F_DESTRUCTIVE flag\n"); + return -EACCES; + } } if (err) diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c index 4be976cf7d63..3ee888507795 100644 --- a/kernel/trace/bpf_trace.c +++ b/kernel/trace/bpf_trace.c @@ -1304,6 +1304,8 @@ bpf_tracing_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog) return &bpf_find_vma_proto; case BPF_FUNC_trace_vprintk: return bpf_get_trace_vprintk_proto(); + case BPF_FUNC_panic: + return capable(CAP_SYS_BOOT) && destructive_ebpf_enabled() ? &bpf_panic_proto : NULL; default: return bpf_base_func_proto(func_id); } diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h index 4423874b5da4..e2e2c4de44ee 100644 --- a/tools/include/uapi/linux/bpf.h +++ b/tools/include/uapi/linux/bpf.h @@ -3927,6 +3927,12 @@ union bpf_attr { * Return * The 64 bit jiffies * + * void bpf_panic(const char *msg) + * Description + * Make the kernel panic immediately + * Return + * void + * * long bpf_read_branch_records(struct bpf_perf_event_data *ctx, void *buf, u32 size, u64 flags) * Description * For an eBPF program attached to a perf event, retrieve the @@ -5452,6 +5458,7 @@ union bpf_attr { FN(tcp_send_ack), \ FN(send_signal_thread), \ FN(jiffies64), \ + FN(panic), \ FN(read_branch_records), \ FN(get_ns_current_pid_tgid), \ FN(xdp_output), \
Add a helper that will make the kernel panic immediately with specified message. Using this helper requires kernel.destructive_bpf_enabled sysctl to be enabled, BPF_F_DESTRUCTIVE flag to be supplied on program load as well as CAP_SYS_BOOT capabilities. Signed-off-by: Artem Savkov <asavkov@redhat.com> --- include/linux/bpf.h | 1 + include/uapi/linux/bpf.h | 7 +++++++ kernel/bpf/core.c | 1 + kernel/bpf/helpers.c | 13 +++++++++++++ kernel/bpf/verifier.c | 7 +++++++ kernel/trace/bpf_trace.c | 2 ++ tools/include/uapi/linux/bpf.h | 7 +++++++ 7 files changed, 38 insertions(+)