周会时间&地址
- 会议周期及时间： 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 |
周凯韬 |
樊宙 |
【公告】原定于 8.29 周四晚九点的 SIG-Main 周会推迟到本周日（9.1）晚上九点
20240829(0901) Sig-Main会议总结
分享人： 池克俭
主题：关于引入自动化内核测试的设想
关于引入自动化内核测试的方案设想
内部测试：syzkaller 模糊测试
Syzkaller 是一个无监督的、覆盖率引导的内核模糊测试工具，它能够自动化地生成随机的系统调用序列，并将其作为测试用例输入到内核中，以此来发现内核中可能存在的漏洞。syzkaller是谷歌开源的，业界正在使用的解决方案。
外部测试：基于固定用例与UI的测试
模拟开发者的行为，例如可以通过 VNC 拿到 QEMU 里面的数据，在启动阶段定时每隔一小段时间来截一次图，判断现在这个状态是卡住了，还是说崩了，还是说正确正常的进入到了系统里面。
而当然这里其实有可能可以做更多的工作，比如说基于用例的去做，进到系统之后，可以跑一些现有的拿来做单元测试的用户空间的测试程序。好处是这是一个固定用测试用例的，对比起模糊测试，会更加精准，能清楚的知道各个模块的测试覆盖情况；并且时间上开销也比较小。
可能需要使用 AI 或者 OCR 来辅助实现这样的需求。
讨论关于引入syzkaller模糊测试的方案
在使用 Syzkaller 进行模糊测试时，需要被测的内核处于运行状态。Syzkaller 通过生成系统调用并将其发送到运行中的内核来执行测试。这些系统调用序列是随机生成的，目的是尽可能覆盖内核代码的各种执行路径，以便发现潜在的错误或漏洞。
Syzkaller 的工作流程通常包括以下几个步骤：
- 启动 Syzkaller 管理器（syz-manager），它会根据配置文件启动一个或多个虚拟机（QEMU）或物理机。
管理器会将 Syzkaller 生成的测试用例（系统调用序列）发送到虚拟机或物理机上运行的内核中。
内核执行这些系统调用，并产生执行结果，如正常返回、异常、崩溃等。
- Syzkaller 收集执行结果，并根据结果更新其测试策略，优先执行那些能够增加代码覆盖率的测试用例。
通过持续的测试和反馈，Syzkaller 能够发现并报告内核中的错误。
- 在实际应用中，Syzkaller 可以配置为在隔离的环境下运行，例如通过 SSH 连接到远程物理机或使用虚拟机。在这种情况下，被测内核需要在目标机器上运行，并且 Syzkaller 需要能够通过网络与之通信。
- 明确引入syzkaller框架的方式是在测试环境（Linux）物理机上使用 qemu，远程（使用ssh等方式）在DragonOS里面跑一个进程，或者说启动相应的测试程序，捕获对应的信息。
需要引入基础支持
-
需要考虑重新考察支持 no-graphic
-
sshd的支持
打包磁盘镜像的问题
20240912 SIGMAIN 会议总结
联合文件系统 overlayfs
分享人：操丰毅
主题：联合文件系统 overlayfs 的作用和实现方式
主要分享了联合文件系统（overlayfs）的作用和实现方式。overlayfs可以将一个或多个文件系统结合在一起。主要有两个层次：上层为读写层，下层为只读层。在容器启动时，下层的只读层会提供最小的OS内核，而上层读写层的容器镜像则可以共享下层的资源。可以简单理解为内核态和用户态的关系；
overlayfs 是 Union File System的一种实现，它可以将多个文件系统合并为一个虚拟的文件系统。overlayfs 有三个层次：上层、下层和合并层。上层是可读写的，下层是只读的，合并层是上层和下层的结合的结果。
通过 COW(写时复制) 机制，在上层创建文件和文件夹，然后将其拷贝到下层进行修改，最后合并成一个虚拟的 merge 层。
此外，还介绍了 WhiteOut 和透明文件夹（opaque directory）两个比较特殊的机制。
WhiteOut
上层文件会把下层文件覆盖掉，这种覆盖关系是通过 WhiteOut 文件来实现的。
WhiteOut 是一个特殊的文件，用于标记上层文件系统中被删除的文件。当上层文件系统中的文件被删除时，overlayfs 会在下层文件系统中创建一个 WhiteOut 文件，表示该文件已被删除。WhiteOut 文件的存在会覆盖下层文件系统中的同名文件，使其在上层文件系统中不可见。
Opaque Directory
默认合并行为：
当上下层某个路径下有同名目录的时候，默认情况下他们的内容会合并在一起，合并层中会看到两者的所有文件。
不透明目录的作用：
上层标记为透明目录的话，下层的文件会被隐藏，即使原本不应该被覆盖到，所以合并层中只会看到上层的文件。
eBPF in DragonOS
分享人：陈林峰
主题：eBPF in DragonOS——ebpf的运行流程，用户态支持和内核支持
eBPF 的运行过程
从用户态和内核态的角度简述一下 eBPF 的运行过程：
-
generate：用户态程序通过 BPF 系列的系统调用生成 eBPF 字节码。
-
load：将 eBPF 字节码加载到内核中，在内核中verifier会对 eBPF 字节码进行验证，然后通过kprobe, uprobes, tracepoint, perf_event等机制将 eBPF 字节码挂载到内核的各个 hook 点上。
-
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，这个系统调用比较复杂。
-
预期输出的地点是伪文件系统下，目前暂时以打印的方式呈现。
