本来想买一本 O Level （中考）单词书，结果随便翻一页一堆单词不认识，最后回滚到初二单词书可能更适合我这种辣鸡😀

顺便买了一本语法书，我的语法简直烂完了。团建时美国人吐槽瑞士人写个猜谜纸条都有语法错误，我看了半天不知错在哪里😀

读《eBPF云原生安全》第三部分的云端乱想

1. 获取进程名最好不要使用 bpf_get_current_comm()、task->comm，而要用 task->mm->arg_start。用下面的命令自己看区别

bpftrace \-e 'tracepoint:syscalls:sys\_enter\_clone* {printf("%s, %s, %s\n", comm, curtask\->comm, str(uptr(curtask\->mm\->arg\_start)));}'

1. BPF_KSYSCALL 糖太甜啦！其实我不是很喜欢这种甜度的糖，包括 BPF_PROG、BPF_KPROBE 等，掩盖了每类 bpf 各有不同参数 context 的细节，本来简单的概念包了一层之后反而我看不懂了。

2. BTF tracepoint 非常好！然后你惊讶地发现 bpftrace -e tracepoint 居然没有利用这项四年前就合并的功能，这难道不是给 bpftrace 做贡献的好机会？(@ _) 从性能上看把 bpf_probe_read 调用都优化成一条 load mem 指令，没有理由不用它。

3. 入口事件+返回事件联合 trace，先暂存事件到 map 再在返回时读出来设置上 retval 是比我更好的思路，我蠢到用两个独立事件在用户态关联，笑死。用 PERCPU_ARRAY 获得更好性能。

4. bpf_send_signal 想过异步信号问题没，即，信号可能并不会立刻投递给进程？对于 SIGKILL 来说没问题，对有些信号可能有问题吗，急需重新背诵 TLPI。

5. bpf_probe_write_user 在有些桌面 linux 默认禁用，比如 ubuntu 2204 integrity lockdown。以前用 Dell ubuntu 的时候也必须把 BIOS secure boot 关了才行。但是似乎 Ubuntu server 2204 又可以用它。

6. 我才知道经典的 tcpdump 的实现已经支持接受 ebpf 了。tcpdump 是通过 socket(AF_PACKET, SOCK_RAW) 然后 setsockopt(sock, SOL_SOCKET, SO_ATTACH_FILTER, cbpf_prog) 来实现的。现早已支持 setsockopt(sock, SOL_SOCKET, SO_ATTACH_BPF, ebpf_fd) 使用 ebpf 过滤。其实这里有很大的想象空间，比如支持一下对 mark, cb, 甚至 sk 的过滤和输出肯定是可以做到的。甚至进程关联岂不是也易如反掌。

7. 用 cgroup/{connect4, connect6, sendmsg4, sendmsg6} + bpf_get_socket_cookie 来关联 skb 和进程信息似乎是更好的做法，我也是从那个项目学到的。

8. iter/task_file 太吓人了，岂不是我们 ~~可以~~ 必须搞一个 bpf iter 版本的 lsof ? 考虑到 lsof 那蹩脚的无限循环 open /proc/*，bpf 版本性能十倍起跳很合理吧（

9. kprobe/fd_install 记录 fd 的 filename 很精彩，但是unix socket 传递 fd 之类的情况是不是就漏了？fork 继承 fd 的情况呢？算了管他的😋

10. bpf 隐藏进程的能力很吓人。如果能用 bpf_probe_write_user 那 bpftool 的输出也一样能篡改，一个精心编写的已经获取 root 的挖矿进程借助 bpf 可以做到：top/ps 不显示正确的 cpu 使用率、隐藏恶意进程、隐藏恶意 bpf 程序、隐藏恶意流量。不知怎么办，管他的，睡觉要紧。

能给我带来启发和思考的书我都觉得是好书，算是迟来的推荐吧🥵感谢黄老师来上海捧场且没有在QA环节把我问得下不了台的不杀之恩

- 我很难解释为什么我要自费来上海参加 pycon china 2024，总之家人问起来我都说是公司的任务可以报销，然后大家就露出一副“工作要紧”的表情严肃地点头。如果我说这是我七年前的梦，不知有多少人会骂我白痴，多少人说一句无聊？

- 七年前，侯老师带着公司的任务参加 pycon china 2017，洪教授和毅总至少三次带他排练演讲，我虽然觉得主题稍有“主人的任务”感，但是内心暗自希望我也能有朝一日走上舞台。走上舞台在那时候我的心中是有点神圣的事情，我说的不只是 pycon 舞台，而是世界的舞台。“让世界看到你”，虽然我不知自己何时能做到。这段话实在太中二了，就权当是不死的理想主义精神吧。

- 有些讲师会在演讲前一天才写 slides，第二天依然能口吐莲花侃侃而谈。我不行，我手脚发软，在上台前五分钟触发肠易激综合征，浑身抖得跟松果痰抖五连鞭似的。我相信罗永浩的“100倍时间”定理：演讲的准备时间，从准备大纲到制作幻灯片，彩排，需要演讲本身100倍的时间，比如1小时的演讲，需要100小时来准备。商业发布会演讲对节奏甚至走位的要求都很高，技术演讲不必纠结这些，但是技术演讲需要准备编程材料正好又弥补了走位的准备时间，我相信一百倍时间适用于我这种笨人。

- 但说实话我也不知道我这次的表现如何，只记得我低头滔滔不绝的时候用旁光看到第一排的其他讲师纷纷低头玩手机。去年在 SRECON APAC 讲 bpf for golang tracing 的时候，讲完走出场被几个印度工程师围过来热烈地握手，纷纷表示从 gdb 开始就完全听不懂但是实在是太酷辣，不知我的此次表演能为多少玩家带来启发，希望能吸引一些小孩对基础设施感兴趣：山谷下面虽然阳光很难企及，但是那里独特的风景甚至更美，只要足够热情和细心，你甚至能亲自活捉几只抱脸虫，为人类文明做一点微小的贡献。

- 我又见到了黄老师，我说奥格四面开花十项全能天天凌晨三四点睡觉，为 pycon 无偿奉献了无数时间这次还自己倒贴一万多块做周边，与此同时还为 cpython 做了不少非平凡的贡献。我说另一个黄老师在内核 bpf 子系统卷得飞起天天搞技术军备竞赛焦虑得我睡不着觉只能把他频道屏蔽了。我说你们二黄一奥都是除了编程没有其他爱好的卷王，哪像我每天做锻炼打游戏都排在日程表里，和你们搞军备竞赛就是死路一条，我打算换赛道了，转型成男同恋爱频道，主打秀恩爱。

- 我又拥抱到了奥格。我们想起十年前在校园认识的场景，这十年简直是看着彼此成长。我吐槽自己晋升后工作恶心，一想到下周又要定小组 sprint 我就想死，现在唯一的希望是收购蜜月期过后公司把 cilium 产品线整锅端掉我就又可以领裁员金了，不然这日子也太难熬了。我看着他第三次说明年一定不参加 pycon，看着他低头默默刷手机吃饭拒绝社交，知道他虽然在台上眉飞色舞但是内心有很多苦闷。小时候我给英雄鼓掌，现在我只关心英雄过得开心吗。我宁愿你少做点贡献，换来更幸福的生活。

- pycon 之后，希望大家都变成快乐的星猫！快乐没烦恼，永远不会老！

https://t.me/mozillazgH/3

我喜欢 ptcpdump，光凭一个功能就足够有用： 关联包的进程信息。

在 ptcpdump -i any $FILTER 在输出的第三列就默认输出 pname 和 pid，在最后列输出 ppname 和 ppid，有趣，有用。比如你能学到冷知识： tcp 被动握手的 syn-ack 回复包其实是关联到主动握手的进程。

还可以 ptcpdump --pid $PID $FILTER 看指定进程的包，由于上一条的冷知识要注意这抓不到服务端的 tcp 握手~ （sockmap redirect 的时候更是什么都抓不到 😬）

由于它的实现，其实和 tcpdump 抓包结果并不完全相同，比如 tcpdump 不能抓 egress tc redirect 的包但是 ptcpdump 可以。这正合我意，能推断 skb redirect。

像是 pwru 和 tcpdump 的中间态，pwru 看不到一个包的 tcp flags 或者 dns qname 总会让我用起来很不方便，而 ptcpdump 好比 pwru --filter-func tc_run + tcpdump 级别的 payload 解析。

我的典型用法是先用 ptcpdump 做粗粒度过滤，缩小到具体的 skb 再用 pwru 观察生命期。

笑死了，这个弱智 bug 导致的 verifier error 查了一小时?

struct { \_\_uint(type, BPF\_MAP\_TYPE\_PERCPU\_ARRAY); \_\_uint(max\_entries, 1); \_\_type(key, u32); \- \_\_type(value, sizeof(struct event)); + \_\_type(value, struct event); } events SEC(".maps");

（大家都好有耐心，朋友在 “朽木不可雕也” 打了两小时才打过，然后给出的评论是 “本以为很难，结果发现对非魂玩家太友好了，手残党也可以继续打了”。而我：五次打不过，毫无头绪，准备弃游直接开始云?