Is it possible to modify a syscall's arguments using bpftrace

[Taeyang123456]

I'm new to eBPF, and I'm studying bpftrace. I have read the Linux Kernel Document - Kprobes, and it says that Kprobe can change register set and so that change the execution path.

I'm wondering whether it is possible, in bpftrace, to probe a syscall and modify its arguments so that the syscall do something we want? If we can do this, how?

[viktormalik]

Hi @Taeyang123456, I think that this is not possible with eBPF.

What is possible is to override the syscall's return value, in bpftrace this is done using the override builtin. This only works if your kernel is compiled with CONFIG_BPF_KPROBE_OVERRIDE and the function you override must be tagged with ALLOW_ERROR_INJECTION (which, AFAIK, all syscalls are).

[Taeyang123456]

Thank you for your reply!

But I'm still confused about the text in the Kprobe document, which says we can change register set and change the execution path. This attracts me because if we can "write" something to the kernel memory area, we can change behavior of syscall to do many things. However, all eBPF related tools/documents only provide "kernel-read" related method, not "kernel-write" related method. So I'm wondering how to make "changing execution path" happen? Is that only means we can force a syscall to directly return without executing function body by overriding the syscall's return value instead of changing the execution path at the function entry?

Another doubt that follows is that, what does eBPF verifier do to "write" behavior in eBPF program? My foolish opinion is that to ensure kernel security, verifier will not allow any "write" behavior to security-related area, such as kernel stack, CPU-register and so on. If so, it's easy to understand why eBPF cannot have "write" behavior in some area.

[viktormalik]

You're basically correct, BPF verifier will not allow writing to arbitrary kernel memory. The thing about kprobes is that BPF is not the only way to leverage them. Kprobes are a general kernel mechanism available both directly to the kernel and to other tools such as perf or SystemTap. Some of these allow to override register values and change function's execution path.

[Taeyang123456]

With the introduction in eBPF document , we can see, for example, BPF_ST, BPF_STX, BPF_LD and more instructions. So if an eBPF program use bytecode directly, maybe it can do something that cannot be done under some high level eBPF abstractions like bcc, bpftrace, right?

[viktormalik]

That's right, but the verifier still wouldn't allow you to override arbitrary kernel memory. AFAIK, you always need to use a helper for that.

[Taeyang123456]

Yes, the verifier should check the bytecode and avoid dangerous behavior, I guess.

Thank you for your reply, it helps a lot!