cilium / pwru

Packet, where are you? -- eBPF-based Linux kernel networking debugger
Apache License 2.0
2.86k stars 175 forks source link

Unable to track BPF helpers in XDP programs #445

Open brb opened 3 weeks ago

brb commented 3 weeks ago

I was expecting that pwru is able to track BPF helpers called by XDP progs when running with --filter-trace-xdp --filter-track-bpf-helpers. That turned to be not the case.

The --filter-track-bpf-helpers relies on attaching the kprobe_skb_by_stackid kprobe to the BPF helper functions. The latter is implemented by --filter-track-skb-by-stackid and friends.

In order to track BPF helpers from XDP, we need to extend --filter-track-skb-by-stackid to support XDP. Its kprobe calls kprobe_skb(..) https://github.com/cilium/pwru/blob/v1.0.8/bpf/kprobe_pwru.c#L542 (and later on handle_everything(...)). Both do expect to get an skb addr as param, which is not available for XDP. We should probably refactor the kprobe_skb and handle_everything to make it generic. Afterwards, the tracking should work.

jschwinger233 commented 3 weeks ago

Is it possible to unwind stack (to get stackid) in native/offload XDP? Honestly I don't even know if bpf_get_stackid() can be used in XDP, https://docs.ebpf.io/linux/helper-function/bpf_get_stackid/ doesn't show BPF_PROG_TYPE_XDP for this helper.

Sometimes I fear non-generic XDP as they has something to do with hardware 😥

brb commented 3 weeks ago

But we would execute it from the fentry (the fentry/xdp), hence BPF_PROG_TYPE_TRACING is enough?

jschwinger233 commented 3 weeks ago

yes🥵

Asphaltt commented 3 weeks ago

I think static long (*bpf_get_stack)(void *ctx, void *buf, __u32 size, __u64 flags) would be better as this helper puts the stack into the buf. Then, walk the buf to check the stack ids.

AFAIK, tracing is unable to get FP directly.