记录一段失败的可行性验证方案,历时两天多,探索出eBPF kprobe技术的边界。
要谈eBPF kprobe,那就得从Kprobes聊起。
Kprobes
Kprobes内核调试技术,是Linux提供的一种能力。能在内核指令执行过程中动态断点,在不影响内核态指令正常运行的过程中,收集系统的性能数据。
原理简单!内核函数方便利用指令向用户态暴露自己的内存地址。
(所有暴露的内核函数地址都在虚拟文件/proc/kallsyms上可找到!这是Kprobes利用的前提条件!)
Kprobes通过访问内核函数的内存地址,即可向可“埋点”的内核函数的某个位置增加断点(一组回调函数)。当实际执行到“埋点”的内核函数的断点时,跳转指令会跳转到Kprobes句柄注册的“埋点”函数(内存地址)上,而后执行结束,再利用句柄跳转回原来的上下文。
eBPF kprobe
ebpf kprobe动态追踪是利用了Kprobes内核调试技术。
那么,就有了这样的想法。用ebpf kprobe去追踪tcp的关联函数,甚至像Kprobe一样,去修改tcp相关函数的执行逻辑。
当然,有想法就得从可追踪的内核函数入手。bpftrace前端工具可以迅速定位这个需要。
这个是ebpf kprobe可跟踪的部分tcp函数
也囊括了可能用到的inet函数。
于是乎,一番操作!tracing和profiling在过程中没有太多的问题。于是乎,打算开始尝试用ebpf kprobe技术去修改tcp首部选项的内容,看看能不能玩出点花来。
先不说结果,毕竟技术实现也在乎个其中的乐趣。
捋了捋思路,我想在握手的最后阶段发送修改的首部,就得在client