。

本文将对这些新特性进行一点简要的介绍#xff0c;更详细的资料请参考对应的链接信息。

总体而言#xff0c;eBPF

eBPF

引入了大量的新特性。

本文将对这些新特性进行一点简要的介绍更详细的资料请参考对应的链接信息。

总体而言eBPF

在内核中依然是最活跃的模块之一它的功能特性也还在高速发展中。

某种意义上说eBPF

eBPF

辅助函数5.17BPF_LINK_TYPE_KPROBE_MULTI5.18动态指针和类型指针5.19USDT5.19bpf

panic6.1BPF

BPF子系统暴露了内核内部算法和数据结构的许多方面这自然导致了对在内核变化时保持接口稳定性的关注。

长期以来BPF对用户空间不提供接口稳定性保证的立场似乎一直有点问题过去内核开发者发现他们不得不维护那些不打算稳定的接口。

现在BPF社区开始考虑至少为它的一些接口提供明确的稳定性承诺可能意味着什么。

BPF允许由用户空间加载的程序被附加到大量钩子中的任何一个并在内核中运行–在子系统的验证器得出这些程序不会损害系统的结论之后。

一个程序将获得由它所连接的钩子提供给它的内核数据结构的访问权。

在某些情况下程序可以直接修改这些数据从而直接影响内核的运行在其他情况下内核将对BPF程序返回的值采取行动例如允许或不允许某项操作。

还有两种机制内核可以通过它们使BPF程序获得额外的功能。

帮助函数或

“helpers”是为提供给BPF程序而编写的特殊函数它们从扩展BPF时代开始就存在了。

被称为kfuncs的机制比较新它允许任何内核函数被提供给BPF可能会有一些限制。

Kfuncs更简单、更灵活如果它们首先被实现那么似乎不太可能有人会在后来添加帮助器。

也就是说kfuncs有一个重要的限制即它们只能被JIT编译的BPF代码访问所以它们在缺乏JIT支持的架构上是不可用的这个列表目前包括32位Arm和RISC-V尽管增加这两种支持的补丁正在开发中.

每个kfunc都为BPF程序提供了一些有用的功能但几乎每个kfunc都暴露了内核内部工作方式的某些方面。

Reconsidering

https://mp.weixin.qq.com/s/wYDSXuwVgmGw-wmFgBNJcADocumentation/bpf:

Add

https://www.spinics.net/lists/kernel/msg4676660.html

Bloom

布隆过滤器是一种节省空间的概率数据结构用于快速测试一个元素是否存在于一个集合中。

在布隆过滤器中假阳性是可能的而假阴性则不可能。

这个补丁集包括布隆过滤器中可配置数量的哈希值和条目的基准测试。

这些基准大致表明平均而言使用3个哈希函数是最理想的选择之一。

当比较hashmap查找中使用3个哈希值的bloom

filter和不使用bloom

filter的查找对于5万个条目大约快15%对于10万个条目快25%对于5万个条目快180%对于1百万个条目快200%。

BPF:

https://lwn.net/Articles/868024/

Compile

代码中的访问偏移量进行重写解决了不同内核版本中数据结构偏移量不同的问题。

第三在

libbpf

中预定义不同内核版本中数据结构的修改解决了不同内核中数据结构不兼容的问题。

第四在

libbpf

程序可以在开发环境编译完成之后分发到不同版本内核的机器中运行并且也不再需要目标机器安装各种开发工具和内核头文件。

所以Linux

内核社区更推荐所有开发者使用

https://time.geekbang.org/column/article/534577BPF

CO-RE

guidehttps://nakryiko.com/posts/bpf-core-reference-guide/

bpf_loop()

扩展的BPF虚拟机的主要特征之一是内置于内核的验证器它确保所有BPF程序都能安全运行。

不过BPF开发者常常认为验证器有点喜忧参半虽然它能在很多问题发生之前抓住它们但它也很难让人满意。

将其与一个善意但受规则约束且挑剔的官僚机构相提并论并不是完全错的。

Joanne

bpf_loop()

简而言之这就是Koong的补丁的目的。

它增加了一个新的辅助函数可以从BPF代码中调用。

long

loopshttps://lwn.net/Articles/877062/eBPF

Talk:

loophttps://mp.weixin.qq.com/s/neOVsMNVWFbwpTSek-_YsA

这个补丁集增加了新的链接类型BPF_TRACE_KPROBE_MULTI它通过Masami制作的fprobe

API

API允许一次在多个函数上附加探针速度非常快因为它工作在ftrace之上。

另一方面它将探测点限制在函数入口或返回。

bpf:

linkhttps://lwn.net/Articles/885811/

动态指针和类型指针5.19

BPF程序中的所有内存访问都使用验证器进行安全性静态检查验证器在允许程序运行之前对其进行全面分析。

虽然这允许

BPF

程序在内核空间中安全运行但它限制了该程序如何使用指针。

直到最近一个这样的限制是在

BPF

辅助函数使用的元数据相关联以确保对该区域的访问是有效的。

Koong

BPF

https://mp.weixin.qq.com/s/rz4pd41Y-Cet5YVSAKmCRw

USDT5.19

USDT用户静态定义的跟踪探针应用程序中感兴趣的特定位置跟踪器可以在此处挂载检查代码执行和数据。

它们由开发人员在源代码中明确定义通常在编译时用

“–enable-trace”

等标志启用。

静态跟踪点的优势在于它们不会经常变化开发人员通常会保持稳定的静态跟踪

ABI所以跟踪工具在不同的应用程序版本之间工作这很有用例如当升级

PostgreSQL

部分跟踪用户进程https://www.ebpf.top/post/ebpf-overview-part-5/Using

user-space

BPFhttps://lwn.net/Articles/753601/

bpf

BPF子系统的关键卖点之一是加载BPF程序是安全的BPF验证器在允许加载之前确保该程序不会伤害内核。

随着更多的功能被提供给BPF程序这种保证也许会失去一些力量但即便如此看到

Artem

的这个提议加入了一个明确设计为使系统崩溃的BPF助手可能会让人有点吃惊。

如果这个补丁集以类似于目前的形式被合并它将是一个新时代的预兆即至少在某些情况下BPF程序被允许公开地进行破坏。

Savkov

的主要用例之一是内核调试这项任务也经常因为存在一个适时的崩溃转储而得到帮助。

通过使内核的panic()

函数对BPF程序可用Savkov试图将这两者结合起来允许BPF程序在检测到表明开发人员正在寻找的问题的条件时导致崩溃并创建崩溃转储。

Savkov似乎不是唯一想要这种能力的人Jiri

The

https://lwn.net/Articles/901284/

BPF

类型。

这允许BPF程序分配他们自己的对象建立他们的自己的对象层次并使用由BPF

然后我们介绍了对单一所有权BPF链表的支持。

它可以放在BPF映射或分配的对象中并把这些被分配的对象作为元素。

它作为一个侵入性的集合工作。

这样做的目的是为了在将来使分配的对象成为多个数据结构的一部分。

BPF

中做一些有限的内核式编程并允许程序员灵活地从基本的构建块中灵活地构建自己的复杂数据结构。

关键的区别在于这种程序是经过验证的是安全的保存系统的运行时完整性并被证明是没有错误的

分配对象bpf_obj_new,

参考https://lwn.net/Articles/914833/

user

这个补丁集定义了一个新的映射类型BPF_MAP_TYPE_USER_RINGBUF它在一个环形缓冲器上提供了单用户空间生产者/单内核消费者的语义。

除了新的映射类型外还增加了一个名为bpf_user_ringbuf_drain()的辅助函数它允许BPF程序指定一个具有如下签名的回调样本由辅助函数发布到该回调。

voidstruct

*context。

然后程序可以使用bpf_dynptr_read()或bpf_dynptr_data()辅助函数来安全地从dynptr中读取样本。

目前没有可用的辅助函数来确定样本的大小但是如果需要的话可以很容易地添加一个。

libbpf

*ring_buffer_user__reserve(struct

ring_buffer_user

ring_buffer_user__discard(struct

ring_buffer_user

ring_buffer_user__submit(struct

ring_buffer_user

https://lwn.net/Articles/907056/

本文由

https://github.com/eunomia-bpf/wasm-bpf以及在

Wasm