共计 2741 个字符，预计需要花费 7 分钟才能阅读完成。
本刊物旨在为中文用户提供及时、深刻、有态度的 ebpf 资讯。
如果你吃了鸡蛋感觉好吃，还想意识下蛋的母鸡，欢送关注：
笔者的 twitter：https://twitter.com/spacewand…
笔者的 GitHub：https://github.com/spacewander
Merbridge 成为 CNCF sandbox 我的项目
Istio、Linkerd、Kuma 这三个我的项目除了都是 service mesh 之外，还有什么共同点？
它们都能够通过 Merbridge 减速！
Merbridge 是一个旨在通过 ebpf 代替 iptables，给 service mesh 减速的我的项目。作为成立刚满一周年的新我的项目，Merbridge 曾经利用到 kuma 的官网版本当中。最近 Merbridge 又达到了另外一个里程碑 —— Merbridge 正式成为 CNCF sandbox 我的项目。
从 Merbridge 提交给 CNCF 的维护者列表来看，目前该我的项目背地是由 DaoCloud 推动的，半数维护者来自于该公司。不过因为 Merbridge 的地位偏差于底层组件，咱们还是能够置信该项目标中立性。想必该项目标创建之初是为了减速 istio，起初也被 kuma 等非 istio 的 service mesh 所驳回。
在应用 Merbridge 进行一键减速之前，一个典型的 service mesh 的网络通信是这样的：
Merbridge 应用了 ebpf 的 SOCKMAP 性能，在 socket 层面上实现包的转发，绕过其余弯弯绕绕的路线。
在采纳 Merbridge 之后，sidecar 和 app 之间的门路可能显著缩短：
在 Readme 上，Merbridge 把这种变动比喻成穿过了爱因斯坦 - 罗森桥（虫洞），倒是挺贴切。
SkyWalking Rover：应用 eBPF 晋升 HTTP 可观测性 – L7 指标和追踪
https://skywalking.apache.org…
提供及时的抓包信息始终是做接入层的程序员的刚需。在笔者的上上家公司，就有共事应用 pcap 实现了能够交互式抓包的后盾服务。Elastic 公司也有个开源我的项目 packetbeat 反对通过 pcap 或者 af_packet 来常态化抓包。
只反对纯抓包的我的项目都有个限度，那就是无奈跟用户态的更多信息有机联合起来。假如能够把用户态的上下文包容入网络包的信息中，前景将会大大拓宽。比方通过比拟用户态的读写办法和内核中理论的读写操作的时间差和数据量，用户会对利用中的 buffering 状况有更深刻的理解。抑或通过 hook 利用中的 TLS 操作，能够失去未加密的实在的申请内容。
ebpf 填充了纯抓包和纯用户态的可观测性之间的鸿沟。通过 ebpf，用户可能同时在 kprobe 和 uprobe 中记录上下文，把两者紧密结合在一起。
言归正传，SkyWalking Rover 的这篇文章，强调了它对 L7 协定的可观测性。家喻户晓，作为一个跑在内核态外面、对执行形式有强束缚的技术，想要在 ebpf 外面实现残缺的 L7 协定栈是一件很艰难的事。那么 SkyWalking Rover 是如何做到的？
SkyWalking Rover hook 了内核相干的函数，嗅探新连贯的内容。它会读取最开始的一段内容做剖析，猜想其背地采纳的协定。尽管有的协定须要更加简单的解决形式，比方嗅探 websocket 须要剥开里面的 HTTP1 的壳。不过对于绝大多数协定，这样就够了。在实现根本的筛选后，它会把内容转到用户态，交给用户态的解析程序来实现。用户态的解析程序会实现残缺的 L7 协定解析。
Caretta：轻量级的 k8s 服务调用网络可视化工具
https://github.com/groundcove…
作为一个去年 11 月才开始开发的我的项目，Caretta 在最近一个月的 star 增长得飞快，不得不让人拜服 groundcover 这家商业公司的宣发。
groundcover 是一家成立于 2021 年，基于 ebpf 做可观测性的以色列 APM 厂商。Caretta 并非是他们产品的开源版，而是该公司开源进去的小工具。Caretta 是一个轻量级的 k8s 服务调用网络可视化工具，可能梳理集群内不同利用之间的调用关系。这个工具通过 ebpf 获取 Node 上各个连贯的信息，接着在用户态借助 k8s 的上下文把连贯信息翻译成 k8s 的服务调用，而后通过 Prometheus 的标准接口把信息裸露进去，最初提供了 Grafana 报表展现 Prometheus 采集到的服务调用信息。毕竟是才开发了两个月的我的项目，这个工具在 ebpf 方面的逻辑其实并不简单，比拟酷炫的展现，是通过 Grafana 来实现的。
如何应答 eBPF 带来的新攻击方式
https://redcanary.com/blog/eb…
ebpf 这么弱小，肯定会有人把它利用到黑产上。本文提到了一些借助 ebpf 进行不法行为的形式，并且给出若干加固的倡议。
总结起来就两条：
- defense in depth
- 如果不必，禁掉 ebpf 和 / 或 kprobe
对第一条开展说一下。因为 ebpf 可能跑在内核态的，所以通常须要 root 权限，或者 CAP_SYS_ADMIN / CAP_BPF（Linux 5.8 新加的）来跑。然而实际上非特权用户也能跑 ebpf，只是有些性能会被限度。感兴趣的读者能够搜寻下“unprivileged ebpf”。然而，就像大家平时写的代码，内核代码中也不免不会呈现 bug，导致非特权用户绕过限度的状况。
比方上面的博客就剖析了之前一个绕过 Linux ebpf verifier 的安全漏洞：https://stdnoerr.github.io/writeup/2022/08/21/eBPF-exploitation-(ft.-D-3CTF-d3bpf).html
所以思考到非特权用户运行 ebpf 是如此鲜见，咱们大可通过设置 kernel.unprivileged_bpf_disabled 禁用该性能。我查看了手上几个 Linux 设施，开发环境上 unprivileged ebpf 是启用的，而两台 VPS 上 unprivileged ebpf 都是禁用的。不确定这种不同是因为 Linux 发行版，还是因为云厂商的设置。
即便设置了 root 能力跑 ebpf，也不代表居安思危。黑客们能够通过别的伎俩拿到 root 权限，而后在 rootkit 外面植入 ebpf 程序。还有一种思路是采纳供应链攻打，就像 log4j 一样。不过思考到目前如同没有什么利用可能动静依据用户输出执行 ebpf 代码，而且 ebpf 也不能间接 import 他人的代码库，在这一块谈供应链攻打还尚早。
借助 ebpf 的 rootkit 是跑在内核里的，且许多 Linux 加固伎俩也是同样利用在内核里，看来彼此在内核中的奋斗会是长久的攻防战。