Introduce two enhancements for func IP

[Asphaltt]

I encountered the following error days ago.

failed to trace TC progs: failed to trace bpf progs: failed to find address for function pod_XXX of bpf prog SchedCLS(pod_XXX)#108

Then, I realize that we have to improve getting func IP when trace bpf progs.

With commit 55bdaac ("Fix tracing tc-bpf with --filter-track-skb-by-stackid") and my blog Debug a tailcall BUG with fentry, I think it's able to get tracee IP when trace bpf progs.

Then, let me introduce our own get_func_ip() helper for tracing to get tracee IP.

Next, in 'output.go', it's incorrect to get func name when output in JSON format.

Why not correct func IP in bpf in order to make sure event.addr is correct always?

To achieve it, let us do - 1 for kprobe and - 4 for endbr in 'kprobe_pwru.c'. As a result, introduce get_addr() function for kprobe, kprobe-multi, fentry and fexit.

BTW, clean some Go code that was used for tracing bpf progs.

---

• get_func_ip() must be compatible on arm64

Test on arm64:

# ./pwru --backend kprobe --filter-trace-tc --filter-trace-xdp --output-meta --output-tuple --filter-func '.*icmp.*' icmp
0xffff80008000b938 1   ping:363         4026531840 0              lo:1       0x0000 65536 98    [0x00000000,0x00000000,0x00000000,0x00000000,0x00000000] 127.0.0.1:0->127.0.0.1:0(icmp) bpf_prog_3b185187f1855c4c_dummy[bpf](xdp)
0xffff0000c1ee5200 1   <empty>:363      4026531840 0              lo:1       0x0800 65536 64    [0x00000000,0x00000000,0x00000000,0x00000100,0x00000000] 127.0.0.1:0->127.0.0.1:0(icmp) icmp_rcv
0xffff0000c1ee5200 1   <empty>:363      4026531840 0              lo:1       0x0800 65536 56    [0x00000000,0x00000000,0x00000000,0x00000100,0x00000000] 127.0.0.1:0->127.0.0.1:0(icmp) icmp_echo
0xffff0000c1ee5200 1   <empty>:363      4026531840 0              lo:1       0x0800 65536 56    [0x00000000,0x00000000,0x00000000,0x00000100,0x00000000] 127.0.0.1:0->127.0.0.1:0(icmp) icmp_reply
0xffff80008000b938 1   <empty>:363      4026531840 0              lo:1       0x0000 65536 98    [0x00000000,0x00000000,0x00000000,0x00000000,0x00000000] 127.0.0.1:0->127.0.0.1:0(icmp) bpf_prog_3b185187f1855c4c_dummy[bpf](xdp)
0xffff0000c1ee5300 1   <empty>:363      4026531840 0              lo:1       0x0800 65536 64    [0x00000000,0x00000000,0x00000000,0x00000100,0x00000000] 127.0.0.1:0->127.0.0.1:0(icmp) icmp_rcv

---

Test on amd64:

# ./pwru --backend kprobe --filter-trace-tc --filter-trace-xdp --output-meta --output-tuple --filter-func '.*icmp.*' icmp
0xffffaab500600b00 6   <empty>:0        4026531840 0            ens33:2      0x0000 1500  98    [0x00000000,0x00000000,0x00000000,0x00000000,0x00000000] 192.168.241.1:0->192.168.241.133:0(icmp) bpf_prog_3b185187f1855c4c_dummy[bpf](xdp)
0xffff9097a49d1a00 6   <empty>:0        4026531840 0            ens33:2      0x0800 65536 64    [0x00000000,0x00000000,0x00000000,0x00000000,0x00000000] 192.168.241.1:0->192.168.241.133:0(icmp) icmp_rcv
0xffff9097a49d1a00 6   <empty>:0        4026531840 0            ens33:2      0x0800 65536 56    [0x00000000,0x00000000,0x00000000,0x00000000,0x00000000] 192.168.241.1:0->192.168.241.133:0(icmp) icmp_echo
0xffff9097a49d1a00 6   <empty>:0        4026531840 0            ens33:2      0x0800 65536 56    [0x00000000,0x00000000,0x00000000,0x00000000,0x00000000] 192.168.241.1:0->192.168.241.133:0(icmp) icmp_reply

[jschwinger233]

I left a comment regarding platform specific bpf code, other than that I love the way you fetched rip in fentry.

Some minor(?) concerns:

1. I fully understand the context because I read Chinese and we talked about this in private. Martynas (brb) please feel free to ask for more details if commit messages don't elaborate enough.
2. Lack of test is constantly hurting us. I'm not 100% confident in whether this PR won't break anything, considering we already suffered certain symbol-address mapping issue pwru fails to parse helper symbols when --filter-track-bpf-helpers #462. Again, this is not the problem of this PR's author, I'm just saying we (pwru maintainers) might want to prioritize some tasks like "pwru hardening"

[jschwinger233]

I have to confess I don't have enough knowledge to review arm64 part, nor does pwru ci test have any arm environment.

Overall it looks good, only some comments to the (amazing) work in correct_func_ip().

I'm not 100% convinced we should adjust pc in bpf, because we can easily achieve the same in userspace at lower cost in my opinion. For example, a possible, maybe also reliable way to adjust pc is:

func adjustPC(pc uint64) uint64 {
_, ok := kallsyms[pc]func adjustPC(pc uint64) uint64 {
	if _, ok := kallsyms[pc]; ok {
		return pc
	}
	if _, ok := kallsyms[pc-1]; ok {
		return pc - 1
	}
	if _, ok := kallsyms[pc-5]; ok {
		return pc -5
	}
	return 0
}

But I do appreciate how you get pc without pt_regs in fentry, thank you very much.

[Asphaltt]

I'm not 100% convinced we should adjust pc in bpf, because we can easily achieve the same in userspace at lower cost in my opinion. For example, a possible, maybe also reliable way to adjust pc is:

I don't think so.

In userspace, we have to do the same thing like correct_func_ip() with lacking of the exact env info.

However, it's better to detect endbr in userspace by checking the very first insn of JitedInsns() is an endbr insn. I'll do it after #484 being merged.