实验小项目招新：移植skyzaller kernel fuzzing工具到Rust-base OS上

[chyyuu]

目标：（学术研究类）移植skyzaller kernel fuzzing工具到Rust-base OS上

目前全国大学生操作系统比赛内核赛道的很多参赛队实现的OS能够支持Linux应用，所以需要在参赛队自己写的内核上支持运行syzkaller for linux这个内核fuzzing测试工具。

具体步骤

参考syzkaller内核fuzzing测试工具的工作流程列出如下内核功能需支持的要求。硬件环境是qemu for riscv64。总分100分。

1. 支持sshd for linux运行
2. 支持syz-fuzzer for linux运行
3. 支持syz-executor for linux运行
4. 参考/sys/kernel/debug/kcov的输出，直接给出类似格式的输出(不需要实现kcov功能)
5. 实现linux的kcov功能支持，能够产生类似/sys/kernel/debug/kcov的输出
6. 支持完整运行syzaller(注意，为此可能还需要支持上面没有列出的Linux应用或Linux系统调用)
7. 完成设计实现与执行过程分析技术报告

参考

• kcov
• How syzkaller works
• Adding new OS support for syzkaller
• Setup: Debian/Ubuntu host, QEMU vm, riscv64 kernel
• Syzkaller 源码分析(1)-(5)：1、2、3、4、5
• syzkaller on freebsd
• 从0到1开始使用syzkaller进行Linux内核漏洞挖掘
• fuzzing-tutorial经典论文/书籍/博客等
• No Grammar, No Problem: Towards Fuzzing the Linux Kernel without System-Call Descriptions, ndss23

linux syscall相关信息

• linux syscall quick reference
• Analyzing a Decade of Linux System Calls
• A study of modern Linux API usage and compatibility: what to support when you're supporting
• POSIX abstractions in modern operating systems: the old, the new, and the missing
• Transcending POSIX: The End of an Era?

注：偏学术研究类

如有兴趣一起来探索，请联系我 yuchen AT tsinghua.edu.cn OR 微信 id chyyuu

[xushanpu123]

目前研究了starry的代码，与郑友捷做了初步交流，得到了如下信息和计划：
目前准备先做的工作是帮助starry完成部分重构工作，降低process中锁的粒度，使进程wait时也可以处理信号，解决部分死锁问题，准备在解决这个问题的过程中进一步熟悉arceos和starry的结构。
目前制定的学习路线是：
1、axruntime模块中lib.rs中的rust_main，学习内核主核的启动逻辑；
2、starry_libax:了解系统调用接口
3、axtask:arceos原生的任务调度结构，主要看monolithic文件夹下的内容，以便对宏内核适配
4、axprocess：starry进程控制结构
5、axsignal：信号模块，需要了解实例
6、axmem：了解它的地址空间模块
等分析好了这些代码，将进行代码重构工作。我将把代码分析工作也写在本板块中供大家指正。

[chyyuu]

@xushanpu123 https://cicvedu.com/course/101 中的“课堂回放”可以看到arceos组件OS的三次课的视频，请在这个周末学完吧，最好把练习也完成了。

[chyyuu]

你的学习路线，好像对syzkaller没有啥关系。你定的这六点需要花多少时间？syzkaller有哪些应用组成？这些应用需要哪些syscall？在starry上还缺什么才能跑起来这些应用？你的学习路线都没有涉及。你在下周二能做得到啥？下周五能做到啥？我没看到。

[asmcos]

https://jborza.com/post/2021-05-11-riscv-linux-syscalls/ 先看这个页面，根据上面的脚本能否把riscv的 Linux 6.1 的内核整理一个syscall列表。

[xushanpu123]

收到！

[xushanpu123]

已经使用该脚本获取了linux的450个系统调用，接下来将修改脚本将结果导出到excel

[xushanpu123]

已经整理成了excel

[xushanpu123]

工作链接：
https://gitee.com/xushanpu/xsp-daily-work/tree/master/syscalls_analysis

[limingth]

我把 https://gitee.com/xushanpu/xsp-daily-work/tree/master/syscalls_analysis/res.xlsx 导入到腾讯共享文档里，
这样方便在线观看，也可以利用 excel 自带的函数进行统计

【腾讯文档】riscv-linux-syscalls
https://docs.qq.com/sheet/DWVBsVkFoZUN3WVZm?tab=000001

[asmcos]

参考 这个项目里面的系统调用，整理第一步要实现的syscall列表。
https://github.com/js2xxx/umi/blob/master/mizu/kernel/src/syscall.rs

[asmcos]

先把 这个 syscall.rs里面的 系统调用 更新到 https://gitee.com/xushanpu/xsp-daily-work/tree/master/syscalls_analysis 里面的execl文件里，做上实现优先级。

[limingth]

用 excel 表格的 INDEX，MATCH，ISNUMBER，SEARCH 函数组合，实现了一个模糊匹配查找，可以对照 riscv linux syscalls 里的 syscall 函数名，找到在 umi 里实现的名称

@asmcos 是不是要这个效果？

【腾讯文档】riscv-linux-syscalls
https://docs.qq.com/sheet/DWVBsVkFoZUN3WVZm?tab=000001

[chyyuu]

umi是西安交大同学做的。https://github.com/Azure-stars/Starry/ 是清华同学做的，基于arceos，目前刚通过了cyclictest https://github.com/Azure-stars/Starry/tree/feat/cyclictest。将来 @xushanpu123 也是基于 Starry做。 @asmcos @limingth

[asmcos]

@limingth 就是这个效果。

[asmcos]

那现在第一阶段目标任务就是基于Starry，把busybox的 系统调用实现了。让busybox在Starry上运行起来 @xushanpu123

[chyyuu]

这个很不错！每一列是什么含义，我还不清楚。最好还能进行各种查询【腾讯文档】riscv-linux-syscalls
https://docs.qq.com/sheet/DWVBsVkFoZUN3WVZm?tab=000001

[limingth]

已经给两个表都加上了 header 一栏做了解释，主要是从两张表的函数名，通过模糊匹配找出可能的关联关系，并统计总的数量。

[xushanpu123]

starry跑了一部分busybox指令。

[asmcos]

整理这张表里 粉红色部分 busybox需要的syscall，把Starry 已经实现的标识出来，目标任务是补充未实现的syscall。

[xushanpu123]

已经完成了Starry系统调用的初步统计，在umi实现的102个syscalls中，starry实现了其中74个接口（具体是哪些接口已经在李明老师的表格中标记了），还有28个接口没有实现，下一步的目标是先实现这28个系统调用接口。

[asmcos]

好的，接下来就是挨个在Starry上去实现这28个syscall。

[asmcos]

37,_linkat,linkat,".map(READLINKAT, fd::readlinkat)",1 ,
38,_renameat,renameat,".map(RENAMEAT2, fd::renameat)",1 ,
52,_fchmod,fchmod,".map(FCHMOD, fd::fchmod)",1 ,
62,_lseek,lseek,".map(LSEEK, fd::lseek)",1 ,
69,_preadv,preadv,".map(PREADV64, fd::preadv)",1 ,
70,_pwritev,pwritev,".map(PWRITEV64, fd::pwritev)",1 ,
81,_sync,sync,".map(MSYNC, crate::mem::msync)",1 ,
82,_fsync,fsync,".map(FSYNC, fd::fsync)",1 ,
116,_syslog,syslog,".map(SYSLOG, dummy_zero)",1 ,
121,_sched_getparam,sched_getparam,".map(SCHED_GETPARAM, dummy_zero)",1 ,
129,_kill,kill,".map(KILL, signal::kill)",1 ,
130,_tkill,tkill,".map(TKILL, signal::tkill)",1 ,
131,_tgkill,tgkill,".map(TGKILL, signal::tgkill)",1 ,
132,_sigaltstack,sigaltstack,".map(SIGALTSTACK, signal::sigaltstack)",1 ,
155,_getpgid,getpgid,".map(GETPGID, dummy_zero)",1 ,
174,_getuid,getuid,".map(GETUID, dummy_zero)",1 ,
175,_geteuid,geteuid,".map(GETEUID, dummy_zero)",1 ,
176,_getgid,getgid,".map(GETGID, dummy_zero)",1 ,
177,_getegid,getegid,".map(GETEGID, dummy_zero)",1 ,
195,_shmctl,shmctl,".map(SHMCTL, dummy_zero)",1 ,
197,_shmdt,shmdt,".map(SHMDT, crate::mem::shmdt)",1 ,
199,_socketpair,socketpair,".map(SOCKETPAIR, fd::socket_pair)",1 ,
233,_madvise,madvise,".map(MADVISE, crate::mem::madvise)",1 ,
283,_membarrier,membarrier,".map(MEMBARRIER, crate::mem::membarrier)",1 ,
403,_clock_gettime,clock_gettime,".map(CLOCK_GETTIME, clock_gettime)",1 ,
406,_clock_getres,clock_getres,".map(CLOCK_GETRES, clock_getres)",1 ,
407,_clock_nanosleep,clock_nanosleep,".map(CLOCK_NANOSLEEP, clock_nanosleep)",1 ,
412,_utimensat,utimensat,".map(UTIMENSAT, fd::utimensat)",1 ,
422,_futex,futex,".map(FUTEX, crate::mem::futex)",1 ,
程序统计 是29个。

[xushanpu123]

9.6工作总结：
今天上午半天在办返校的事情，下午开始工作，完成工作如下：
1、在starry上跑通了部分busybox的测例；
2、统计了starry上未实现的支持busybox运行的系统调用接口。
接下来的任务:
依次实现何老师列出的29个接口。

[xushanpu123]

今日工作：
1、vscode的rust_analyzer出现了无法启动的bug，重装和更新后解决了；
2、排除了linkat接口（fat32文件系统不支持）；
3、发现starry没有实现的接口renameat2（没有真正work，只进行了简单的flag检查）；
4、查看了rename，renameat和renameat2的接口的区别；
5、查阅了umi中的renameat2代码，发现它实际上实现的是renameat的功能。
后续任务：
借鉴umi的实现，在starry上实现接口renameat和renameat2.

[asmcos]

9.7日

[xushanpu123]

利用接口open_at为切入点，做了个简单的代码分析，大概分析了一下starry和arceos的文件系统接口，分析到了node层次，目前应该够用了，分析链接：
https://gitee.com/xushanpu/xsp-daily-work/blob/master/starry_interface_analysis

[xushanpu123]

今日工作：
今天本来计划做renameat接口，在写的过程中发现必须熟悉整体架构才能更好的完成任务，因此转而开始研究starry的整体结构，今天主要研究的是文件系统部分，今天具体工作如下：
1、设计了renameat接口的逻辑，即修改旧文件和新文件的父目录的内容，在旧目录中删除旧目录项，在新目录中添加新目录项，其中新目录项copy旧目录项，只修改文件名；
2、研究了文件系统的多个接口，对文件系统的结构理解到了node层级，具体分析工作在链接https://gitee.com/xushanpu/xsp-daily-work/blob/master/starry_interface_analysis中；
3、研究了一下Directory的结构和接口。
后续目标是用会目录检索和目录增删的接口，若没找到现成的接口，就自己实现一个。另外，一个并发的工作是做出starry文件系统部分的函数调用关系图，以便后续实现所有文件相关的syscall。

[mengmengjiang1999]

syzkaller参考：

https://www.collabora.com/news-and-blog/blog/2020/03/26/syzkaller-fuzzing-the-kernel/
大概讲了syzkaller的工作流程

https://www.collabora.com/news-and-blog/blog/2020/04/17/using-syzkaller-to-detect-programming-bugs-in-linux/
syzkaller的用法

https://www.collabora.com/news-and-blog/blog/2020/05/12/using-syzkaller-fuzzing-your-changes/
进一步的用法

https://www.collabora.com/news-and-blog/blog/2020/06/26/using-syzkaller-part-4-driver-fuzzing/
驱动fuzz（感觉这个用处不是很大）

[mengmengjiang1999]

https://kiprey.github.io/2021/11/syzkaller_1/

一个看起来很不错的文档

[mengmengjiang1999]

（前段时间有点事下线了一段时间）总之今天把syzkaller跑起来了

[mengmengjiang1999]

跑是跑起来了，不过一晚上过去了，也没挖出什么洞（意料之中

[mengmengjiang1999]

1. 先按照setup.md文档里写的，先配置好go环境，然后编译出syz-manager的二进制文件（在/bin/文件夹下），并编译出待测试的os的镜像（不管在哪个文件夹下都可以，总之要记好命令），然后在config文件中给出go路径、syzkaller路径、镜像文件路径等，然后通过./bin/syz-manager -config my.cfg启动。启动后可以看到一个这样的界面，就会显示出目前挖出的漏洞的情况。

不过因为我按照用户文档的指示，运行的是一个稳定版本的linux，所以跑一晚上也没有什么漏洞也是正常的。

2. 关于syzkaller的结构

分3个部分。

syz-manager会启动好几个VMinstance（一般翻译成实例？），然后在VM中启动syz-fuzzer进程。

syz-fuzzer进程管fuzz的一系列流程。它跑在等待被测试的不稳定的VM里面。（也就是说syz-fuzzer（看起来是一个用户态进程）会用到什么系统调用，那就是被测试的内核需要支持的功能）然后它就会去引导fuzz的那一套流程。通过RPC和syz-manager通信。它生成的输入似乎就是一系列的系统调用。（好神奇

每个syz-executor会执行一次用户输入（用户输入就是一系列的系统调用），它接收syz-fuzzer给出的用户输入，然后执行，然后将结果返回。通过共享内存和fuzzer通信。

[mengmengjiang1999]

1. 先按照setup.md文档里写的，先配置好go环境，然后编译出syz-manager的二进制文件（在/bin/文件夹下），并编译出待测试的os的镜像（不管在哪个文件夹下都可以，总之要记好命令），然后在config文件中给出go路径、syzkaller路径、镜像文件路径等，然后通过./bin/syz-manager -config my.cfg启动。启动后可以看到一个这样的界面，就会显示出目前挖出的漏洞的情况。

不过因为我按照用户文档的指示，运行的是一个稳定版本的linux，所以跑一晚上也没有什么漏洞也是正常的。

2. 关于syzkaller的结构

分3个部分。

syz-manager会启动好几个VMinstance（一般翻译成实例？），然后在VM中启动syz-fuzzer进程。

syz-fuzzer进程管fuzz的一系列流程。它跑在等待被测试的不稳定的VM里面。（也就是说syz-fuzzer（看起来是一个用户态进程）会用到什么系统调用，那就是被测试的内核需要支持的功能）然后它就会去引导fuzz的那一套流程。通过RPC和syz-manager通信。它生成的输入似乎就是一系列的系统调用。（好神奇

每个syz-executor会执行一次用户输入（用户输入就是一系列的系统调用），它接收syz-fuzzer给出的用户输入，然后执行，然后将结果返回。通过共享内存和fuzzer通信。

[mengmengjiang1999]

总之我觉得，既然syz-fuzzer是跑在带测试的VM里面的，那么syz-fuzzer会用到什么内核功能，就是移植到新的内核上要写的东西。

总之把syz-fuzzer的代码看了一遍。（虽然不知道有什么用···

一些关键问题：

1. syz-fuzzer测试哪些系统调用？有一个sys文件夹，里面有系统调用模板。然后syzkaller有一套自己定义的“系统调用序列语言”，通过syz-extract和syz-sysgen来将其转换为go语言，然后交给syz-fuzzer执行。
2. manager是如何启动syz-fuzzer的？通过ssh，具体在manager.go文件中，runInstance。syz-manager在runInstance函数中把syz-fuzzer和syz-executor复制到VM中，调用FuzzerCmd函数通过ssh执行syz-fuzzer。
   https://xz.aliyun.com/t/5223?time__1311=n4%2BxnD07itGQ0QYG%3DDCDlhje0%3DA%3DAKfAvKqtx&alichlgref=https%3A%2F%2Fgithub.com%2Forgs%2Frcore-os%2Fdiscussions%2F38

此外关于syzkaller的源码分析：

syz如何描述自己要测试的系统调用？以及在Linux上增加一个新的系统调用后如何用syzkaller进行测试，见：

https://xz.aliyun.com/t/5079?time__1311=n4%2BxnD07iti%3DK0KDt%3DDsA3xCqbymY5NDuDYwD&alichlgref=https%3A%2F%2Fgithub.com%2Forgs%2Frcore-os%2Fdiscussions%2F38

这些系统调用模板通过syz-extract和syz-sysgen翻译成syzkaller使用的代码

https://xz.aliyun.com/t/5098?time__1311=n4%2BxnD07iti%3DIxQqiKDsA3xCqbyDBGD7uWnRRmD&alichlgref=https%3A%2F%2Fgithub.com%2Forgs%2Frcore-os%2Fdiscussions%2F38

[mengmengjiang1999]

哦，对这个流程恍然大悟（大雾
支持sshd for linux运行：因为syz-manager是通过ssh启动syz-fuzzer的（不过还是不太懂如何在VM里启动的syz-fuzzer，看起来很高级的样子啊）
支持syz-fuzzer for linux运行：不用多说了，因为syz-fuzzer是跑在被测试的VM里的
支持syz-executor for linux运行：同理
参考/sys/kernel/debug/kcov的输出，直接给出类似格式的输出(不需要实现kcov功能)
实现linux的kcov功能支持，能够产生类似/sys/kernel/debug/kcov的输出
支持完整运行syzaller(注意，为此可能还需要支持上面没有列出的Linux应用或Linux系统调用)
完成设计实现与执行过程分析技术报告

[mengmengjiang1999]

既然如此，我觉得可以先开始写点东西，比如说先支持sshd for rt-thread。（怎么做啊QAQ

[mengmengjiang1999]

所以为什么要做这个？统计它有啥用啊QAQ

https://docs.qq.com/sheet/DWVBsVkFoZUN3WVZm?tab=000001

[mengmengjiang1999]

https://docs.qq.com/sheet/DWVBsVkFoZUN3WVZm?tab=000001

https://gitee.com/xushanpu/xsp-daily-work/blob/master/syscalls_analysis/res.xlsx

https://gitee.com/xushanpu/xsp-daily-work/tree/master/syscalls_analysis

[mengmengjiang1999]

还是先看下这个吧。https://www.rt-thread.io/document/site/programming-manual/basic/basic/
（估计1-2个工作日）

[mengmengjiang1999]

The thread scheduler of RT-Thread is preemptive and its main job is to find the highest priority thread from the list of ready threads so as to ensure that the highest priority thread can be run. Once the highest priority task is ready, it can always get the CPU usage right.

https://www.rt-thread.io/document/site/programming-manual/thread/thread/

dinamic thread and static thread

线程管理

感觉跟普通OS好像没什么明显区别（？不确定再看看

clock

In RT-Thread, the length of clock tick can be adjusted according to the value of RT_TICK_PER_SECOND, which is equal to 1/RT_TICK_PER_SECOND second.
用户可以自己定义每个rt_tick（不妨翻译成时间片）是多少个周期，然后实现也很显然，就是每次时钟中断的时候计数器+1。

Software timer是rt-tick的整数倍

可以创建并且激活很多个timer，然后他们通过一个叫做rt_timer_list的东西按照顺序组织起来。还有一个Timer Skip List Algorithm让插入timer的复杂度是O(logn)。

后面讲了很多timer的用法。

Inter-thread Synchronization

（srds这样干看好没意思啊=，=而且好像对写代码没什么帮助

[mengmengjiang1999]

啊啊啊为什么rt-thread的env工具只有Windows能用···

[mengmengjiang1999]

其实是要测试下fuzzer需要什么系统调用。那么能不能想个办法单独跑一下syz-fuzzer？比如说我觉得我应该在某个Linux机器上单独跑一下这个syz-fuzzer，然后测试系统调用。
理论上来说应该可以在两台不同的机器上起manager和fuzzer，然后在其中一台上面用strace测试。
另外还有个办法就是魔改一下代码，在虚拟机里面strace，然后想办法把结果搞出来。但是我觉得还是上面那种做法好搞一点。