关于 eBPF 的一点个人看法

花了一些时间，了解了一下ebpf 的功能、代码、for windows 使用，

看了一下相关的逻辑，

目前个人感觉是，不宜应用到我们自己的项目中，

以下所说”脚本“，均指”开发人员修改的规则文件，形式是gnuc 代码“。

优势：速度快，各种速度都快

开发：一套框架，直接用到死

修改规则：开发人员直接使用C语言来按照格式写脚本，然后使用特定的编译器来编译脚本，之后，将脚本下发给客户端之后，客户端可以再处理编译好的脚本逻辑，把它插入到自己的逻辑中，以实现逻辑的热更新，

缺点：

为了提高规则匹配效率，实际上开发的逻辑是在驱动层直接执行的，这就直接导致一个问题，就是万一写规则的时候随便写错点什么，结果可能就是BSOD。

规则要求用C语言来写，难度极高。且语法为GNUC 语法，相对我们 VC 开发并不友善。就编译器而言，仅能使用LLVM编译，GCC都不行，因为实际上编译出来的是 BPF 平台的伪码，LLVM 通过定制平台来实现针对 BPF 平台来编译，其他编译器目前无新增此功能。

LLVM 编译时，各种命令需要手敲，整套工具链都不友好。

内部逻辑复杂，由于LLVM编译出来的文件是elf格式的文件，所以针对”脚本“编译出来的也是elf文件，需要在我们项目中集成一个elf解析器，来解析对应的elf 文件。有点类似”从dll 中扣 shellcode“ 的意思，但是这个 shellcode 是在客户端上加载规则的时候现扣的。

它需要极专业的人，来使用特定的语言来开发一套基于C语言的代码，相关语法延续C语言，但是内部关键字、函数等全部使用bpf支持的，需要大量学习练习bpf 相关开发。体现在学习、使用的角度上，人力成本及后续的使用成本非常高。维护成本可能很低，但是依然会有，一些特定的功能需要定制化在引擎内部开发，很类似于给lua引擎提供接口，供脚本使用。

这东西本质上和一套内核级脚本没有区别，仅仅是因为它的出现较早，即1992年，那时候还没有什么比较成熟好用的脚本，lua 是1993年才出现的。如果站在脚本的角度上的话，我们有更多选择，有更多更成熟的脚本解决方案，不一定要使用它。难道仅因为它名气很大么。

虽然有针对性的工具BCC（https://raw.githubusercontent.com/windywolf/example/master/eBPF/bccsample.py）能方便地处理相关编译、伪码提取等功能，但是BCC是 Python 做的，也只能做一些简单的工作，无法从根本上解决整套架构的使用问题。

它内部维护的数据，绑定方式为 key => value 对的逻辑绑定，是精确绑定，没有模糊查找的功能针对我们的需求，有些水土不服。

以上缺点，大多数情况下，都不算缺点，但是对我们来说，成本太高。

虽然可以将其移植到上层，供上层使用，但是如果是这样的话，那我们用其他任意一种成熟的语言都可以解决问题啊。

综上：

此解决方案看似很好，但是专业性，要求太高，成本太高，可以做完，但是做完之后，后续改动成本也非常高。

若仅从结构上看，其整体架构与lua没有本质区别，内部依然是一套vm执行各种相关指令，仅仅是将lua的 op_code 变成了 bpf 的 op_code 。

现有可参照项目为 ebpf for windows 。编译环境很费劲。

如果有时间，或者有需要，这玩意可以做一个组内分享，但是感觉，其实没啥必要，如果真的捞干的说，这玩意其实很简单，就是代码乱七八糟，又没有比较详细的资料，看起来比较累。

在个人的角度看：

它是一个时代的产物，在1992年那个时代，驱动开发不易，且linux内核是个标准的宏内核框架，如果要对其中一个驱动模块做修改，那么实际上是需要有一整套内核源码的，虽然不用重新编译一整套内核源码，但是依旧开发不易，编译不易，又没有比较好的脚本框架可供使用，bpf框架在那个时代出现，解决了大问题，这毫不稀奇。之前如果需要改驱动逻辑，要大学linux内核，还需要整体内核重编，在这个环境下，bpf框架支持了在外部修改逻辑，脚本式的直接插入，在不改代码的情况下，修改其相关内部逻辑，这个技术在当时那个年代绝对是非常超前的。