Skip to content

bpf: Harden getting func ip#609

Merged
brb merged 3 commits intocilium:mainfrom
Asphaltt:fix/harden_func_ip
Oct 22, 2025
Merged

bpf: Harden getting func ip#609
brb merged 3 commits intocilium:mainfrom
Asphaltt:fix/harden_func_ip

Conversation

@Asphaltt
Copy link
Contributor

@Asphaltt Asphaltt commented Oct 6, 2025

Closes #602

Since commit torvalds/linux@7d1cd70d4b16ff (v6.13), the private stack of bpf programs was introduced for fentry.

As a result, when the private stack is used for fentry, it cannot retrieve the function IP by unwinding rfp.

To avoid the issue caused by the private stack, it is able to retrieve the function IP by unwinding trampoline's rfp, which is ctx + 8 always for our case.

Copy link
Contributor

@Andreagit97 Andreagit97 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tested it locally and everything works fine! thanks!
LGTM

@Asphaltt Asphaltt marked this pull request as draft October 8, 2025 09:57
@Asphaltt Asphaltt force-pushed the fix/harden_func_ip branch from f0e420b to 09064ce Compare October 8, 2025 09:57
@Asphaltt Asphaltt marked this pull request as ready for review October 8, 2025 10:27
@brb
Copy link
Member

brb commented Oct 21, 2025

@Asphaltt Thanks for the patch again! If we apply your patch, then do we need to bump a min kernel requirement for --filter-tracke-{xdp,skb} and --filter-track-bpf-helpers to 6.13?

Since commit torvalds/linux@7d1cd70d4b16ff (v6.13), the private stack of
bpf programs was introduced for fentry.

As a result, when the private stack is used for fentry, it cannot
retrieve the function IP by unwinding `rfp`.

To avoid the issue caused by the private stack, it is able to retrieve
the function IP by unwinding trampoline's `rfp`, which is `ctx + 8`
always for our case.

Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
When trampoline was introduced for arm64, `bpf_get_func_ip()` was
introduced at the same time.

See commit torvalds/linux@efc9909fdce0 ("bpf, arm64: Add bpf trampoline for arm64").

Therefore, it is able to get the IP of tracee using this helper.

Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
When the stack layout become more and more complicated, it is not
reliable to detect the FP of trampoline by checking possible range.

To get rid of the stack layout, which will be updated along the kernel,
detect the FP of trampoline by utilizing the `ctx` of current fentry
prog. As for our case, there is only one argument, `skb` or `xdp`, on
the stack of trampoline for tracee. Therefore, it is able to confirm the
FP by checking whether the IP beyond the FP is the IP of tracee.

         * |  lr  | IP of tracee
         * |  fp  | FP of tracee
         * +------+ FP of trampoline  <--------- detect it
         * |  ..  | padding
         * |  x20 | always
         * |  x19 | always
         * |  arg | skb/xdp always for our case
         * +------+ ctx of current prog

Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
@Asphaltt
Copy link
Contributor Author

do we need to bump a min kernel requirement for --filter-tracke-{xdp,skb} and --filter-track-bpf-helpers to 6.13?

No, we don’t need to bump the minimum kernel requirement.

This change simply gets rid of the private stack feature, since the ctx always points to the trampoline’s stack — ever since the trampoline was introduced.

@brb brb merged commit 10cee81 into cilium:main Oct 22, 2025
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

fentry_tc bpf prog doesn't correctly track the ebpf program address to which it is attached

4 participants