On Thu, Jun 6, 2024 at 3:03 PM Yan Zhai <yan@xxxxxxxxxxxxxx> wrote:
>
> Hi,
>
> I am building a tracing program around workqueue. But I encountered
> following problem when I try to record a function pointer value from
> trace_workqueue_execute_end on net-next kernel:
>
> ...
> libbpf: prog 'workqueue_end': BPF program load failed: Permission
> denied
> libbpf: prog 'workqueue_end': -- BEGIN PROG LOAD LOG --
> reg type unsupported for arg#0 function workqueue_end#5
> 0: R1=ctx(off=0,imm=0) R10=fp0
> ; int BPF_PROG(workqueue_end, struct work_struct *w, work_func_t f)
> 0: (79) r3 = *(u64 *)(r1 +8)
> func 'workqueue_execute_end' arg1 type FUNC_PROTO is not a struct
> invalid bpf_context access off=8 size=8
> processed 1 insns (limit 1000000) max_states_per_insn 0 total_states 0
> peak_states 0 mark_read 0
> -- END PROG LOAD LOG --
> libbpf: prog 'workqueue_end': failed to load: -13
> libbpf: failed to load object 'configs/test.bpf.o'
> Error: failed to load object file
> Warning: bpftool is now running in libbpf strict mode and has more
> stringent requirements about BPF programs.
> If it used to work for this object file but now doesn't, see --legacy
> option for more details.
> ...
>
> A simple reproducer for me is like:
> #include "vmlinux.h"
> #include <bpf/bpf_helpers.h>
> #include <bpf/bpf_tracing.h>
>
> SEC("tp_btf/workqueue_execute_end")
> int BPF_PROG(workqueue_end, struct work_struct *w, work_func_t f)
> {
> u64 addr = (u64) f;
> bpf_printk("f is %lu\n", addr);
>
> return 0;
> }
>
> char LICENSE[] SEC("license") = "GPL";
>
> I would like to use the function address to decode the kernel symbol
> and track execution of these functions. Replacing raw tp to regular tp
> solves the problem, but I am wondering if there is any go-to approach
> to read the pointer value in a raw tp? Doesn't seem to find one in
> selftests/samples. If not, does it make sense if we allow it in
> the verifier for tracing programs like the attached patch?
>
> Yan
>
> ---
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 821063660d9f..5f000ab4c8d0 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -6308,6 +6308,11 @@ bool btf_ctx_access(int off, int size, enum bpf_access_type type,
> __btf_name_by_offset(btf, t->name_off),
> btf_type_str(t));
> return false;
> + } else if (prog->type == BPF_PROG_TYPE_TRACING || prog->type == BPF_PROG_TYPE_RAW_TRACEPOINT) {
> + /* allow reading function pointer value from a tracing program */
> + const struct btf_type *pointed = btf_type_by_id(btf, t->type);
> + if (btf_type_is_func_proto(pointed))
> + return true;
The reason it wasn't supported in tp_btf is to avoid potential
backward compat issues when the verifier will start to recognize it
as a proper pointer to a function.
Since I didn't know what that support would look like I left it
as an error for now.
'return true' (which would mean scalar type to the verifier)
is a bit dangerous and I feel it's better to think it through right away.
Eventually it probably will be a new reg_type PTR_TO_KERN_FUNC or something.
And it won't be modifiable.
Like arithmetic won't be allowed.
Passing into other helpers (like prinkt in your example) is fine.
But if we do 'return true -> scalar' today then bpf prog
will be able to do math on it, including conditional jmps,
which will be disallowed once it becomes PTR_TO_KERN_FUNC.
And that would become a backward compat issue.
So pls think it through from that angle.
