LWN: BPF 中也能panic!

Linux News搬运工

共 2074字,需浏览 5分钟

 ·

2022-08-03 05:48

关注了就能看到更多这么棒的文章哦~

The BPF panic function

By Jonathan Corbet
July 18, 2022
DeepL assisted translation
https://lwn.net/Articles/901284/

BPF 子系统的关键卖点之一,就是加载 BPF 程序的动作是安全的:BPF verifier 这个验证器会在允许加载 BPF 程序之前就确保它不会伤害内核。随着给 BPF 程序赋予了更多的 capability,这种保证也许会变弱化,但即便如此,当看到 Artem Savkov 的这个提议来增加一个让系统 crash 的 BPF helper 的时候,也还是会让人感到有些惊讶的。如果这个 patch set 能以目前的这种形式合并进来,那么它就会是预示着一个新时代,在这个时代,至少在某些情况下,BPF 程序可以公开地进行破坏性操作。

正如 Savkov 所指出的,BPF 的主要使用场景之一就是用于内核调试,这项任务也经常需要在恰当的时间生成一个 crash dump 来进行调试。通过让 BPF 程序可以使用内核的 panic() 函数,Savkov 就将这两者结合了起来,从而允许 BPF 程序在检测到那些开发人员正在寻找的问题出现了的特殊情况下直接触发 crash,并创建 crash dump。Savkov 似乎不是唯一想要这种功能的人;Jiri Olsa 指出,他也收到了关于这种功能的请求。

将 panic()提供给 BPF 有一些很明显的危险后果,所以人们期望这里会有一些防护。在这种情况下,首先的防护就是新增的一个 flag,即 BPF_F_DESTRUCTIVE。当加载一个将会调用破坏性操作(如 panic() 函数)的程序时,就必须提供这个 flag。如果这个 flag 不存在,BPF 验证器就会拒绝加载包含调用任何破坏性 helper 函数的程序,目前 panic() 是唯一一个。

即使如此,panic() 的 helper 函数也只对 tracing 程序可用。毕竟,总不应该让一个红外解码器就能让系统 panic 吧,也就是这一限制会阻止人们在 BPF 中实现具有 "panic" 按钮的遥控器。然后,还有一个新的 sysctl 开关(kernel.destructive_bpf_enabled)要设置为非零值;否则就将不允许调用 panic()。即使设置了 sysctl 开关,代表 BPF 程序运行的进程也必须具有 CAP_SYS_BOOT 这个 capability。

总而言之,BPF 程序似乎不太可能误操作让系统 panic。

对这个 patch 似乎没有太多的反对意见,尽管有细节问题。例如,Song Liu 不喜欢这个 sysctl 开关,"因为它是全局有效的,用户很容易忘记用完后把它关闭掉"。Alexei Starovoitov 也说,在这种情况下不需要 sysctl,CAP_SYS_BOOT 检查应该就足够了。Starovoitov 还质疑是否有必要让系统完全 panic,因为有更直接的方法来创建一个 crash dump。Savkov 回答说,panic()是 "更通用的" 做法,而且系统对 panic 的处理动作也是可以由管理员配置的。他确实同意删除 sysctl 开关。

Starovoitov 还建议将该功能作为一个 kfunc 而不是 BPF helper 来实现。这里的理由是,kfuncs 被认为是不够稳定的,如果它们被证明是一个坏主意的话可以随时被删除,而删除 BPF helper 则比较困难。当然,值得注意的是,到目前为止,这个关于 kfuncs 的可移除性的立场还没有经受过愤怒的用户挑战(也就是某个用户的应用程序如果依赖了一个刚刚被移除的 kfunc 时会产生的抱怨)。

在后来的回应中,Starovoitov 质疑 panic() 的 "versatility",并说应该让 BPF 程序使用更底层的函数。因此,应该有一个用于创建 crash dump 的函数,以及一个用于向 console 发送消息的函数,一个用于 halt 系统的函数,一个用于重启的函数,等等。他说,这样一来,BPF 程序本身可以决定应该发生什么,而不是取决于系统中的具体配置情况。

显然,这套 patch 的另一个版本将在未来出现,而且它可能看起来与第一次有很大不同。但似乎很明显,在 BPF 程序中存在这种 "破坏性" 功能的使用场景。BPF 系统正在迅速发展,已经超越了数据包处理以及信息收集的范围,它的发展方向是把各种内核功能都提供给 BPF 程序。目前还不清楚这一切最终会导致什么样的未来,但很可能会是一个有趣的未来。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作~

长按下面二维码关注,关注 LWN 深度文章以及开源社区的各种新近言论~



浏览 35
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报