LWN: 重新思考bpfilter和user-mode helper！

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

Rethinking bpfilter and user-mode helpers

By Jonathan Corbet
June 12, 2020
原文来自：https://lwn.net/Articles/822744/

bpfilter 子系统，以及与之配合使用的"user-mode blobs"机制，在2018年合入Linux 4.18的时候吸引了很多人的注意。不过在那之后，相关的开发哪怕是用很宽容的说法来形容，也是非常克制的。现在已经合入2年了，bpfilter却有可能会作为一个失败的试验品从kernel里面移除了。

Some history

bpfilter是Linux kernel里面的又一个packet-filtering（包过滤）系统，跟netfilter和nftables很像，它是用在防火墙相关领域的。bpfilter不打算提供用户可能会用到的所有那些filtering primitives，而仅仅是加载BPF program来审查网络包来决定是accept还是reject。理论上来说，bpfilter有着非常大的优势。它可以替换kernel里面的许多防火墙相关代码，处理效率很可能比起netfilter和nftables要快许多，同时扩展性也更好。因此许多人都希望看到bpfilter今后能取代其他的防火墙方案，成为Linux系统中的标准。

不过，要想达成这个目标，bpfilter开发者还需要做许多工作。除了继续完善那些过滤功能以外，还需要找到方法来避免破坏现在世界上正在基于netfilter正常运行的那数百万设备。这些系统的管理员已经花了许多时间来建立适合他们自己的防火墙配置文件，很可能不希望再要去学习BPF从头开始开发一次。如果没有无缝衔接的兼容办法，bpfilter就无法取代netfilter。

bpfilter开发者选择的解决方案就是再重新实现netfilter的user-space API，这样现有的工具和配置文件就可以仍然正常工作了。而在kernel内部，这些netfilter rule实际上会被转化成BPF program来attach到相应的位置。这个方案对大家都有好处：能在完全不让用户改动的情况下来替换成一个新的packet-filtering subsystem。

唯一的问题是，用BPF来实现这些netfilter rule可不是一件轻松的工作。kernel里面已经有大量代码都是为了应对user space可能传进来的各种异常参数进行针对性地处理。代码量很大，占用memory就会过多，此外要想让这部分代码能达到security要求也会非常困难，在完全开发完成之前肯定会引出不少新的CVE报告。

为了避免这个问题，大家发明了"user-mode blob"这个概念。开发者也经常把它叫做"user-mode helper"（这个名字其实在kernel里已经存在很多年了，指的是user space按照kernel要求运行的一个程序）。本文里面也会用user-mode helper这个称呼。user-mode helper在这里指的是编译到kernel内部的一个可执行程序。在需要执行的时候，可以把它当做一个独立的、user-space的进程来运行起来，跟kernel采用pipe（管道）方式进行通讯。在对netfilter rule进行翻译转换的时候，这个helper程序会从user space读入rule，在一个可以对memory进行换入换出并且不会增加kernel暴露的漏洞的环境下对rule进行转换，然后把结果写入kernel。

在合入bpfilter和user-mode helper功能的时候，人们认为这是可以广泛应用的功能。Greg Kroah-Hartman 称之为 "非常通用的、崭新的user/kernel API，会有许多开发者希望利用这个机制", 并且许多人因此猜测Linux kernel最终也会走向微内核（microkernel）架构。

...and then?

不过在代码合入之后，这方面似乎冷却了下来。bpfilter领域没有看到更多值得介绍的开发工作，kernel里面也没有其他地方利用user-mode helper。当最近有个bug报告没有得到bpfilter的任何一位开发者的回应的时候，Eric Biederman 仔细看了看相关代码，认为这里情况很不好：

这部分代码的maintainer一直没有回复过。我看了一下代码历史，在代码合入mainline之后，相关改动都是一些很微小的维护工作。没有看到有真正在按原计划继续进行功能开发。

他指出了这些代码中一些已知问题，给出建议说最直接的解决这些bug的方法就是把bpfilter和user-mode helpers移除。

在kernel中提出删除某人的代码的建议，通常是一个很有效的方法来获取相关人员的注意。这次也很有效。Alexei Starovoitov很快就跳出来反对这个建议 。Linus Torvalds也发话了, 他指出这部分代码其实根本就没有用起来，也对最开始提出使用user-mode helper的这个主意表示质疑：

如果人们确实需要把netfilter rule转化成bpf，他们会更愿意在user space来做这件事。bpfilter功能还没有任何进展，并且它确实已经导致了一些问题。所以，Alexei，我认为应该是你来提供证据证明自己的观点，而不是Eric。

Starovoitov 回复说 bpfilter功能花费的时间要比预期的多。主要的困难在于BPF限制了可以实现的rule集合的大小。最近才刚刚克服这些限制，主要是得益于5.8版本中合入的"BPF iterator"功能，所以“不久之后bpf就能处理几百万条rule了”。后面他又 补充说：他并不反对现在把bpfilter功能拿掉，可以等到今后在这个领域有了切实进展（至少需要6个月时间）之后再恢复回来。

不过，他表示user-mode helper功能还是非常重要的，应该保留在kernel中。除了bpfilter用到了它以外，他还指出了其他几个使用者。首先是 /proc 的一个扩展功能，这里会用到BPF iterator机制来在运行时创建新的类似 =/proc=的文件。还有一个用户是一个initramfs的变种，会被内置入kernel，并在启动过程中早期阶段就建立好各种subsystem。Kroah-Hartman 说，他一直有个计划就是想用user-mode helper来在user space实现USB驱动，不过他也没法保证什么时候能真正动手。

user-mode helper这个理念的问题在于目前并没有一个真正的实用例子。因为没人用它，所以相关的bug也都没有暴露出来，代码也就没有进步，其他的开发者没有样例可以参考。如果有些有趣的功能可以用user-mode helper来实现出来，情况就可能会改变。而如果没有这样的例子的话，这就是个很充足的证据来说明这个功能本身并没有那么有价值。

这个讨论中，关于是否要删除代码，目前还没有结论。根据过去的经验来看，有开发者积极争取保留的情况下很少有代码被移除的情况。不过就算是这样，人们肯定不会同意一直保留这些没有用处的代码的。如果后续没有真正的进展的话，最终这还是会作为一个没有成长起来的试验性工作而被移除的。

全文完

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

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

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