LWN: BPF 中也能panic!

news/2024/7/7 13:27:00 标签: 内核, java, python, 编程语言, 区块链

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

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 深度文章以及开源社区的各种新近言论~

format,png


http://www.niftyadmin.cn/n/732836.html

相关文章

LWN:BPF 中可以长存的指针!

关注了就能看到更多这么棒的文章哦~Long-lived kernel pointers in BPFJuly 14, 2022This article was contributed by David VernetDeepL assisted translationhttps://lwn.net/Articles/900749/BPF 子系统允许程序员编写一些可以在内核空间安全地运行的程序。BPF …

LWN:支持Intel线性地址屏蔽功能!

关注了就能看到更多这么棒的文章哦~Support for Intels Linear Address MaskingSupport for Intels Linear Address MaskingDeepL assisted translationhttps://lwn.net/Articles/902094/一个 64 位的指针可以对海量的内存进行寻址,远远超过真实世界中一…

LWN:塞满return stack buffer!

关注了就能看到更多这么棒的文章哦~Stuffing the return stack bufferBy Jonathan CorbetJuly 22, 2022DeepL assisted translationhttps://lwn.net/Articles/901834/"Retbleed" 系列漏洞,是一类牵涉到 return 指令的投机执行(spec…

LWN: Docker 以及 OCI 容器生态!

关注了就能看到更多这么棒的文章哦~Docker and the OCI container ecosystemJuly 26, 2022This article was contributed by Jordan WebbDeepL assisted translationhttps://lwn.net/Articles/902049/Docker 已经改变了许多人开发以及部署软件的方式。它不是第一个在…

LWN:从KVM直接进行host系统调用!

关注了就能看到更多这么棒的文章哦~Direct host system calls from KVMBy Jonathan CorbetJuly 29, 2022DeepL assisted translationhttps://lwn.net/Articles/902585/虚拟化机制的设计原则之一就是要在 host 和它所运行的 guest 系统之间提供强大的隔离。guest 是不…

LWN: 6.0 合并窗口,第一部分!

关注了就能看到更多这么棒的文章哦~6.0 Merge window, part 1By Jonathan CorbetAugust 5, 2022DeepL assisted translationhttps://lwn.net/Articles/903487/预计是 "6.0" 版本内核的合并窗口已经有了一个强劲的开端,在最初的几天里就有了 68…

LWN: 基于io_uring的用户空间块设备驱动!

关注了就能看到更多这么棒的文章哦~An io_uring-based user-space block driverBy Jonathan CorbetAugust 8, 2022DeepL assisted translationhttps://lwn.net/Articles/903855/在 6.0 合并窗口期间,很容易会忽略掉新加入的 ublk 驱动;它被深…

LWN:针对用户命名空间的安全模块hook!

关注了就能看到更多这么棒的文章哦~A security-module hook for user-namespace creationBy Jonathan CorbetAugust 4, 2022DeepL assisted translationhttps://lwn.net/Articles/903580/Linux 安全模块(LSM)子系统的基本工作机制就是在内核中…