2024下半年SIG-Main周会公告&会议总结

SIG - Main
1

周会时间&地址

  • 会议周期及时间： SIG-Main将从2024年8月1日起，每两周，逢周四晚9点举行SIG会议
  • 会议号：#腾讯会议：586-9766-3285

周会要分享什么？

为了避免开发者闭门造车，也为了让大家都能对项目的整个进展有所把握，SIG周会的分享制度涉及的内容可以是对于SIG-Main涉及的技术问题的看法/思路、最近正在做的工作、进度以及遇到的需要讨论的问题，或者是过往的一些开发经验，并不需要是成型的子项目或者成果，大家不必担心自己还没成型的产出而不敢分享汇报。作为一个加强沟通的常态化方式，希望大家积极参与。

为什么轮流分享？怎么轮流？

为了让这个制度更好的执行下去，考虑到由于目前 SIG-Main、SIG-Virtualization、SIG-Observation.Test 、SIG-Cloud_Provider 和 SIG-MM 以及做编辑器的同学，都是合并开会的，人数比较多，范围比较广，我们将统计这几个SIG中的成员，每次会议轮流让两位同学来做主要分享和汇报，其他同学可以以自由讨论的方式进行。

目前项目组内部已经在前两次会议中做过分享的同学有：谢润霖、陈林峰、杨璐玮、操丰毅，所以结合其他成员员，我们制定了一个初步的基本顺序，如无意外情况就按照这个顺序进行，如果个人有特殊情况，请自行联系一下其他同学进行交换。

如果我们有遗漏或者有其他问题，请联系我~

如果轮到你了，你应该提前准备什么

周会之前，我们会在公众号上提前几天发布预告，所以你需要至少提前两天准备好分享的内容和材料（简明的PPT或者文档），并把分享汇报的标题在【2024下半年】SIG-Main周会议题&内容分享征集 下回帖，后续交由运营同学去发表公众号推文。

序号 汇报人1 汇报人2
1 谢润霖 陈林峰
2 杨璐玮 操丰毅
3 龙进 池克俭
4 黄铭涛 何懿聪
5 侯嘉滢 曾俊
6 许梓豪 许浩捷
7 胡兆朋 庄凯烨
8 周泳森 朱炜豪
9 周凯韬 樊宙
2

【公告】原定于 8.29 周四晚九点的 SIG-Main 周会推迟到本周日（9.1）晚上九点

4

20240829(0901) Sig-Main会议总结

分享人： 池克俭

主题：关于引入自动化内核测试的设想

关于引入自动化内核测试的方案设想

内部测试：syzkaller 模糊测试

Syzkaller 是一个无监督的、覆盖率引导的内核模糊测试工具，它能够自动化地生成随机的系统调用序列，并将其作为测试用例输入到内核中，以此来发现内核中可能存在的漏洞。syzkaller是谷歌开源的，业界正在使用的解决方案。

image
image741×771 25.1 KB

外部测试：基于固定用例与UI的测试

模拟开发者的行为，例如可以通过 VNC 拿到 QEMU 里面的数据，在启动阶段定时每隔一小段时间来截一次图，判断现在这个状态是卡住了，还是说崩了，还是说正确正常的进入到了系统里面。

而当然这里其实有可能可以做更多的工作，比如说基于用例的去做，进到系统之后，可以跑一些现有的拿来做单元测试的用户空间的测试程序。好处是这是一个固定用测试用例的，对比起模糊测试，会更加精准，能清楚的知道各个模块的测试覆盖情况；并且时间上开销也比较小。

可能需要使用 AI 或者 OCR 来辅助实现这样的需求。

讨论关于引入syzkaller模糊测试的方案

在使用 Syzkaller 进行模糊测试时，需要被测的内核处于运行状态。Syzkaller 通过生成系统调用并将其发送到运行中的内核来执行测试。这些系统调用序列是随机生成的，目的是尽可能覆盖内核代码的各种执行路径，以便发现潜在的错误或漏洞。

Syzkaller 的工作流程通常包括以下几个步骤：

  1. 启动 Syzkaller 管理器（syz-manager），它会根据配置文件启动一个或多个虚拟机（QEMU）或物理机。

管理器会将 Syzkaller 生成的测试用例（系统调用序列）发送到虚拟机或物理机上运行的内核中。

内核执行这些系统调用，并产生执行结果，如正常返回、异常、崩溃等。

  1. Syzkaller 收集执行结果，并根据结果更新其测试策略，优先执行那些能够增加代码覆盖率的测试用例。

通过持续的测试和反馈，Syzkaller 能够发现并报告内核中的错误。

  1. 在实际应用中，Syzkaller 可以配置为在隔离的环境下运行，例如通过 SSH 连接到远程物理机或使用虚拟机。在这种情况下，被测内核需要在目标机器上运行，并且 Syzkaller 需要能够通过网络与之通信。
  • 明确引入syzkaller框架的方式是在测试环境（Linux）物理机上使用 qemu，远程（使用ssh等方式）在DragonOS里面跑一个进程，或者说启动相应的测试程序，捕获对应的信息。
需要引入基础支持

  • 需要考虑重新考察支持 no-graphic

  • sshd的支持

打包磁盘镜像的问题

  • 调查能否在非特权级下完成磁盘进行打包

  • 调查特权级打包磁盘镜像后是否能够在 GitHub CI上运行

  • 参考 asterinas 调研一下是怎么完成这个流程的

  • 相关的讨论：

5

20240912 SIGMAIN 会议总结

联合文件系统 overlayfs

分享人：操丰毅

主题：联合文件系统 overlayfs 的作用和实现方式

image
image1280×716 46.3 KB

主要分享了联合文件系统（overlayfs）的作用和实现方式。overlayfs可以将一个或多个文件系统结合在一起。主要有两个层次：上层为读写层，下层为只读层。在容器启动时，下层的只读层会提供最小的OS内核，而上层读写层的容器镜像则可以共享下层的资源。可以简单理解为内核态和用户态的关系；

overlayfs 是 Union File System的一种实现，它可以将多个文件系统合并为一个虚拟的文件系统。overlayfs 有三个层次：上层、下层和合并层。上层是可读写的，下层是只读的，合并层是上层和下层的结合的结果。

通过 COW(写时复制) 机制，在上层创建文件和文件夹，然后将其拷贝到下层进行修改，最后合并成一个虚拟的 merge 层。

此外，还介绍了 WhiteOut 和透明文件夹（opaque directory）两个比较特殊的机制。

image
image1280×741 64.5 KB

WhiteOut

上层文件会把下层文件覆盖掉，这种覆盖关系是通过 WhiteOut 文件来实现的。

WhiteOut 是一个特殊的文件，用于标记上层文件系统中被删除的文件。当上层文件系统中的文件被删除时，overlayfs 会在下层文件系统中创建一个 WhiteOut 文件，表示该文件已被删除。WhiteOut 文件的存在会覆盖下层文件系统中的同名文件，使其在上层文件系统中不可见。

Opaque Directory

默认合并行为：

当上下层某个路径下有同名目录的时候，默认情况下他们的内容会合并在一起，合并层中会看到两者的所有文件。

不透明目录的作用：

上层标记为透明目录的话，下层的文件会被隐藏，即使原本不应该被覆盖到，所以合并层中只会看到上层的文件。

eBPF in DragonOS

分享人：陈林峰

主题：eBPF in DragonOS——ebpf的运行流程，用户态支持和内核支持

eBPF 的运行过程

image
image1011×425 55.8 KB

从用户态和内核态的角度简述一下 eBPF 的运行过程：

  1. generate：用户态程序通过 BPF 系列的系统调用生成 eBPF 字节码。

  2. load：将 eBPF 字节码加载到内核中，在内核中verifier会对 eBPF 字节码进行验证，然后通过kprobe, uprobes, tracepoint, perf_event等机制将 eBPF 字节码挂载到内核的各个 hook 点上。

  3. async read：eBPF 程序在 hook 点上运行，执行完毕后将结果(statistics)写入到 eBPF map 中。perf_output 机制可以将结果(per-event data)异步输出到用户态。

用户态支持

用户态的eBPF工具库很多，原理大致相同。目前 DragonOS 选择了AYA框架作为用户态支持。但是由于部分系统调用的支持问题，需要对AYA框架进行删改。

Tokio

Tokio 是一个基于 Rust 的异步运行时，用于构建高性能的网络应用程序。DragonOS 现在已经基本支持 Tokio 运行时。

内核态支持

内核态支持主要分，kprobe，rbpf，系统调用支持，helper 函数支持。

  • kprobe 需要在上一次 PR 的基础上进行修改，配合 eBPF 的运行机制。

  • 原版 rbpf 功能比较简单，因为不是原生为了支持 eBPF，DragonOS 已经基本支持，但是需要结合rust实际的生命周期和所有权规则等添加一些数据结构的支持。

  • 系统调用方面，除了bpf，联通 eBPF 和 kprobe 的系统调用在 Linux 里是 perf_event_open，这个系统调用比较复杂。

  • 预期输出的地点是伪文件系统下，目前暂时以打印的方式呈现。

6

20241024 SIGMAIN 会议总结

分享人：

  • 樊宙 DragonOS内核虚拟化之内存虚拟化
  • 周凯韬 Held 编辑器 Command 模式与 Replace 模式的重构

DragonOS内核虚拟化之内存虚拟化

  1. KVM和QEMU：
  • KVM是Linux内核中的一个模块，能够将Linux内核转变为虚拟机管理程序（Hypervisor），提供硬件虚拟化支持。
  • QEMU是一个开源仿真器和虚拟机管理程序，可以独立运行虚拟机，或与KVM结合使用，主要负责设备仿真和管理虚拟机生命周期。
  1. 内存虚拟化理论：
  • 应用程序获取的内存空间是线性虚拟地址空间，而实际数据交互的是物理地址空间，由MMU负责映射。
  • 虚拟机中的应用程序申请的空间是虚拟地址空间（GVA），映射成虚拟机的物理地址空间（GPA），再通过VMM映射成真实的物理地址（HPA）。
  1. 内存虚拟化技术：
  • 全虚拟化技术：VMM为每个虚拟机维护影子页表，维护GVA与HPA的映射关系。
  • 半虚拟化技术：Guest OS的页表不具备写权限，写请求由VMM维护，将写请求中的物理地址替换成真正的物理地址。
  • 硬件辅助虚拟化技术：硬件辅助完成GPA到HPA的转换，减少了软件层面的开销，提高了性能。
  1. EPT（扩展页表）的优势：
  • 减少CPU开销：硬件直接处理地址映射，降低了CPU开销。
  • 简化系统管理：硬件辅助的页表减少了虚拟机管理程序的复杂性，提高了系统性能。
  1. 内存虚拟化流程：
  • 从CR2读取GPA，从EPTP读取EPT Pointer地址，建立EPT连接，涉及EPT PML4、PDPT、PDT和PT。
  1. 当前进度：
  • 在CPU虚拟化基础上，主要处理EPT_VIOLATION，并建立EPT映射。目前遇到的问题是在映射bootloader时，尽管有EPT页表地址，但仍然不断触发EPT_VIOLATION，原因不明

讨论

Held编辑器Command模式与Replace模式的重构

  1. 工作原理：
  • Held编辑器采用render与listen_event操作循环，即渲染和监听事件循环。
  1. 基本功能：
  • :w：保存文件。
  • :q：退出编辑器。
  • :wq：保存文件并退出编辑器。
  • :q!：强制退出编辑器，不保存修改。
  1. 重构工作：
  • 渲染：在command模式下，通过renderer的render方法进行渲染。
  • 事件执行：包括模式跳转和对基本功能的命令匹配与执行。
  1. 代码实现：
  • Command模式的Renderer：涉及到键位对应的函数映射。
  • 存放输入数据的结构体：用于存储command模式下的输入数据。
  • 事件处理与命令匹配：涉及到事件处理和命令的匹配。
  1. 待完善功能：
  • 查找与替换功能：如:s/foo/bar/g和:%s/foo/bar/gc。
  • Replace模式计划：在normal模式下按下R进入Replace模式，类似于Insert模式，但Replace模式是在当前光标处替换掉buffer中的字符。