2022年6月第三周简报
生活
六月第三周，天气更热了，完全不想出门！
- 本周继续在运动了，体重下降到可170！好耶！
- 身体状态又开始反复了，电话咨询了下医生，可能是药物的问题，可能要换药了！
- 本周看了好多好玩的东西
- 补了 BBC 的纪录片《七个世界一个星球》
- 间谍过家家 EP11，好温馨啊
- 我的信仰电视剧2005年的《海猿》终于找到了！看得我热泪盈眶
- 奥特银河格斗三，我只能说坂本我球球你别拍了
- 本周极端天气好多（
- 朝阳还是不允许堂食，没法去店里改善伙食
- 本周又开始看杂书了，好耶！美滋滋！
本周的看书
- 《人造美人，星新一小说集》
有一说一，星老板的奇怪的幽默感，大开的脑洞太戳我xp了，不愧是溢出道就被认为是天才的人物啊（其实我很怀疑他字里行间透露出来的一种奇怪的冷静感，是他一直在俯视着众生的一种具象化）
技术
- 本周 nerdctl 有个新的 issue Discussion1128，针对 CNI 的一点活。写完了，不过这周状态不好懒得写测试。所以下周交 PR 吧
- 本周花了不少精力去实现安全老哥的“拦截特定进程对于特定文件的打开读写操作”的需求，继续吃屎
- 由于要向下兼容到310，以及某公司的定制版内核对有几个 helper function 支持有限，所以我选择用了 ptrace 去做
- 为啥不用 SELinux 这种已有的姿势去搞定。原因在于后续注入点可能还会借鉴一些 IO Chaos 里的手法，给已经打开敏感文件的恶意进程在读取数据的时候注入一些随机数据。
- 这个 trace 可能需要作为一个常态化的进程跑在机器上，确保在符合规则的恶意进程启动的时候，便可以注入防护功能。Netlink Process Monitoring 监听 fork/exec 几个事件，或者 eBPF 上 kprobe 去监听对应 sys_call 就行，不过考虑到要向下兼容 310 我估计还是会用 Netlink 方案。Easy
- 有个稍头疼的问题，目前 ptrace 常态化 attach 进程的方案存在以下两个问题，所以需要考虑新的方案
- 性能问题
- 进程可以感知到自己被 trace，所以可能需要将 attach 的时间尽可能放短
- 根据上面的问题，目前想到的一种思路是，ptrace 只 attach 一次，给敏感 sys_call 注入一段 jmp 指令，jmp 到我们新指令里。由新指令来校验 paylaod ，然后决定是否放行
- 这周开始复习一下 Kubernetes 中 Kubelet 相关的代码，要开始做提 CPU Burst 相关 KEP 的准备了。以及和 Burst Spec 的作者交流，看他是不是因为工作关系无法顾及社区
- Serverless in the Wild: Characterizing and Optimizing the Serverless Workload at a Large Cloud Provider 这篇论文很有意思啊，有些举出来的数据我觉得挺好玩的
- HTTP 请求是调用函数的最大来源，其次是计时器（或者叫 Crobjob？）
- 45%的应用可以有一个小时被调用一次的频率
- 百分之50以上的应用的单次执行时间在1s以内
- 百分之90的应用内存消耗不超过 400MB
总结
疫情反复，经济下行，大家请务必多保重
Comments
