Post #425

记下最近高强度 debug 所面临的工具短缺问题 1. iptables-tracing。先别提 nft / legacy / ip6tables，光是 nat 就能让人皱紧眉头。比方说最简单的 masquerade，我们当然可以用 -j LOG/TRACE （甚至搞个 .ko）在这个规则被命中的时候打印 skb 和规则本身，但是 nat 自带的 rev-nat 是没有显式规则的。你 SNAT 之后的包发出去，回来的时候要 DNAT 吧，然而这个 DNAT 是没有 iptables rules。更别说 nat 内部奇奇怪怪的 drop 条件，比如 nat conflict，血条直接动态清零。 2. pwru。我最近每天至少要运行 50 次 pwru，然而还是有太多功能缺失了：--filter-mark 需要接受 mask、--filter-track-skb 需要支持 skb_clone、需要有 kretprobe 去接收 retval、需要以生命期为单位过滤（从而可以反向追溯 skb）、需要观测 sk kfuncs、需要正确打印进程名和 ifname、需要反映函数的调用关系、需要在函数结束的时候同样输出 *skb 来确认“就是你干得好事”。 3. pcap filter。需要一些糖来过滤：vxlan 内层 L3/L4、tcp payload。需要简单的办法来指定特定的 tcp 链接（我说的就是 src port）。需要过滤 **tcp 会话**（我记得是大鹅第一次提出这个想法）。 4. gdb。我问遍了 AI 都不知道怎么让 gdb 同时载入 /proc/kcore 和 /proc/kallsyms。我的根本目的是检查 /proc/kcore 里的指令时 gdb 能帮我把 callq 的目标符号打印出来，而已！难不成要我写个工具把 kallsyms text 转成 ELF，这太扭曲了，不 unix。 5. bpftrace。我大量使用 tid 来串联，目前还没出过问题。本质是这样的：在“锚函数”（比如以 skb 作为参数的函数）处，我们可以通过很多手段过滤，确认目标后记录 tid；然后在内层函数处（甚至不用函数，偏移！）通过 tid 串联出当前 skb，做检查和期望的输出。这种多函数串联 tracing 的功能，内核目前只有一个很不好用的 ftrace graph，基本可视为没有过滤功能。我不需要完整的 ftrace，光是一个单层调用的，自解析参数的，带过滤功能的，the little ftrace，就是我想要的。还有 kstack 的 bug，每次我都手动回溯，石器时代是吧。 6. inside a kernel function。ftrace 的粒度还是太大了，就算定位了罪魁祸首的函数，其内部运行逻辑的观测是十分艰难。就算有 retval，你也难以判断内部是哪个 if 导致 goto drop。由于有 ASLR，就算有 dbgsym 也并不能直接拿来使用，但是我发现 offset 是绝妙的观测手段。比如在 /proc/kcore 上观测到 ip_forward() 对一个特定 skb 的运行路径是 +0, +1, +10, +78，那么直接把偏移拿到 dbgsym 上去解读就行了。不过 inline 依然恶心，我们只能期待 inline 本身就没多少指令来肉眼解读。或者反汇编也是一个思路，比如知道某参数是 skb，那么分析汇编就足以知道 mov 0x0, 0x18(%rbx) 是 skb->sk = null，这种弱智工作，就tm应该自动完成，别浪费工程师的时间。