Introduce two enhancements for func IP #468
Draft
+102
−83
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Since commit 55bdaac ("Fix tracing tc-bpf with --filter-track-skb-by-stackid"), we are able to get FP of current bpf prog. Then, from blog [Debug a tailcall BUG with fentry](https://asphaltt.github.io/post/ebpf-talk-138-debug-tailcall-bug-with-fentry/), we are able to get IP of tracee bpf prog like the way of `bpf_get_func_ip()` helper. Therefore, implement our own `get_func_ip()` helper to get IP of tracee bpf prog. Signed-off-by: Leon Hwang <[email protected]>
As we're able to get IP of tracee bpf prog at runtime, remove those code related to name2progName preparation. Signed-off-by: Leon Hwang <[email protected]>
It's better to correct func IP in bpf then in user space, because in bpf it is able to distinguish every case, include endbr case. As a result, it gets `addr` by this `get_addr()` function for **kprobe**, **kprobe-multi**, **fentry** and **fexit**. Signed-off-by: Leon Hwang <[email protected]>
There was a problem hiding this comment.
I left a comment regarding platform specific bpf code, other than that I love the way you fetched rip in fentry.
Some minor(?) concerns:
- 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.
- 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"
| } | ||
|
|
||
| static __always_inline bool | ||
| is_endbr(u32 val) |
There was a problem hiding this comment.
maybe wrap x86 specific code inside #ifdef bpf_target_x86?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I encountered the following error days ago.
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.addris correct always?To achieve it, let us do
- 1for kprobe and- 4for endbr in 'kprobe_pwru.c'. As a result, introduceget_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