On 10/8/19 10:29 PM, Andrii Nakryiko wrote: > On Fri, Oct 4, 2019 at 10:04 PM Alexei Starovoitov <ast@xxxxxxxxxx> wrote: >> >> Disallow bpf_probe_read() and bpf_probe_read_str() helpers in >> raw_tracepoint bpf programs that use in-kernel BTF to track >> types of memory accesses. >> >> Signed-off-by: Alexei Starovoitov <ast@xxxxxxxxxx> >> --- >> kernel/trace/bpf_trace.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c >> index 52f7e9d8c29b..7c607f79f1bb 100644 >> --- a/kernel/trace/bpf_trace.c >> +++ b/kernel/trace/bpf_trace.c >> @@ -700,6 +700,8 @@ tracing_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog) >> case BPF_FUNC_map_peek_elem: >> return &bpf_map_peek_elem_proto; >> case BPF_FUNC_probe_read: >> + if (prog->expected_attach_type) >> + return NULL; > > This can unintentionally disable bpf_probe_read/bpf_probe_read_str for > non-raw_tp programs that happened to specify non-zero > expected_attach_type, which we don't really validate for > kprobe/tp/perf_event/etc. So how about passing program type into > tracing_func_proto() so that we can have more granular control? yeah. that sucks that we forgot to check expected_attach_type for zero when that field was introduced for networking progs. I'll add new u32 to prog_load command instead. It's cleaner too.
