操作系统内核的绝佳学习材料——JOS

Posted 2020-07-28 cdai

操作系统内核的绝佳学习材料——JOS

---

前言：关于JOS和一些经验之谈

这一学期的操作系统课使用的是MIT用于教学的JOS操作系统，并且StonyBrook在其基础上做了大量改动，最重要的变化就是从32位移植到了64位。因为个人之前曾系统学习过Linux 0.11内核（《操作系统内核Hack：(四)内核雏形》，实现到时钟中断部分停下了），深知自己从零开始实现内核的工作量。即便是如我个人实现的Minios这种简单的不能再简单的，也是需要花费很多时间和精力的。虽然这些付出非常值得（在上这门课时给我带来了巨大的帮助），但是对于想直接上手的同学来说会很打击积极性。

既然强烈推荐JOS，那它有哪些好处呢？

1. 环境搭建简单：JOS依赖的软件较少，基本就是GCC、Qemu、GDB这一套。以后如果有人能够做一个Docker镜像的话，那就更方便了。
2. 引导性强：不管是Lab中的文字还是代码里的注释，JOS的作者真的很贴心，几乎所有习题都不会从零开做。尤其是代码中的注释，给出了详尽的指导，很多还都有Hint提示。这对自学的同学来说真的太重要的了。
3. 自动打分：每个Lab都有一个Grade脚本，因为代码中编写了大量的测试断言代码（有的Lab感觉测试代码甚至都要超过功能代码了，非常的全面）。
4. 挑战题目：如果你觉得太简单，每个Lab还有少量的挑战题目，有些可以一试，有些对于我是挺难的。这学期大概做了有十几个相对容易一些的Challenge题，感觉还不到总体数量的一半。从Challenge中真的能学到很多，推荐大家都试试，我后面会给出个人认为非常好的题目。

以下是个人的一点经验，感觉应该比较通用，严格遵守的话能节约很多时间：

• 注释：如果Lab文字不想仔细看的话，那么也行，碰到问题回头再翻。但是：一定要仔细看注释里的提示，差一句话可能就少实现了一种Case，就埋下了一颗“定时炸弹”！
• Bug：不要以为某个Lab满分就OK了，其中隐藏的Bug可能在后面的Lab爆发。这也是JOS实验有趣的地方，这一套代码完全是你自己的，从第一个Lab到最后，你都要完全负责。
• 调试：底层开发的调试工作绝对是考验功力的时刻。有时异常了，有时panic了，有时虚拟机triple error直接崩溃了。这时就需要凭借你的经验和强大的GDB像福尔摩斯一样去找线索，有时通过crash前的寄存器内容能预判，有时先大块定位后再逐行调试，有时凭感觉做出几种可能的猜测再去验证等等。

所以，个人以为JOS是个非常不错的选择，虽然它的确有的地方有些简陋，与真实的Linux有很大差别，但能系统地做完6个Lab的练习的话，对个人绝对是巨大的提升！本文不会“剧透”任何答案，只是总结一些经验心得和最重要的知识点，大家可以放心观看～

如果本文提到的题目、知识点在MIT的Lab中找不到的话，请搜索Stony Brook的Lab进行学习。

---

Lab 1: x86 Assembly and Bootloader

Lab 1的特点是阅读量大，但习题很少，毕竟刚开始还是让大家热身适应一下。不要看文字很多很烦，如果之前没有过内核或者嵌入式开发基础的话，其中一些预备知识还是很重要的，否则后面的Lab你会很痛苦。Lab 1涉及到的预备知识有：Git、Qemu、GDB、Inline汇编、C指针。

最主要的工作就是练习11开始实现backtrace函数的栈打印。之前觉着ebp（rbp）没什么用，真正控制着栈的是esp（esp），甚至像在《CSAPP缓冲区溢出攻击实验(下)》中ebp是错误的也没什么。而在这次实验的最终几道题目中，ebp却发挥了巨大作用，原来esp是在一个栈帧内随着压栈和出栈不断移动，而ebp就像是不同火车车厢（栈帧）之间连接的“钩子”。虽然函数返回时不断出栈，esp最终能够自己正确地返回到调用者。但当我们调试时，例如在GDB中执行bt命令时，是不能改变esp位置去追溯的，这时ebp就该出场了！

关于完成练习所需的代码其实JOS中的DWARF都给了，直接调用就能得到我们想要的东西。但要注意的就是：64位与32位汇编编程的不同！这也是JOS给我的“下马威”。总结一下我做这个最终练习时犯的错误，有些是旧知识忘记了，有些是新知识：

1. 指针（地址）和值的转换：例如rbp要追溯到上一个栈帧的栈基址时可以这样：*((int *)(ebp))。
2. 栈的方向弄反了：栈从高地址向低地址生长。ebp下的低地址是被调用函数的局部变量，ebp上的高地址是调用者的返回地址（原eip）、入参。
3. ebp和eip配对错了：当前ebp和eip是一对，表示当前的数据位置和代码位置。而当前ebp所指位置里的值，与该位置紧挨着的高地址位置保存的返回地址，则是又一对。
4. 64位的调用惯例：前面说到ebp上保存着返回地址和入参，这其实只对32位有效。64位的返回地址的确还是紧挨着ebp，但入参不是必须压栈的。因为64位机器的寄存器很多，从rdi、rsi、rdx、rcx、r8、r9可以保存6个入参，所以只有要调用的函数入参超过6个时才会压栈。

Lab 1只有一个Challenge，就是让输出到控制台的字体改变颜色。要求中介绍了一种通用的控制方法，就是ANSI的ESC序列（Escape sequence），语法是”ESC[Value;…;Valuem”。曾经在设法使MakeFile输出不同颜色字体时遇到过，例如echo -e ‘\\033[31;1mHelloWorld!\\033[0m’（先修改成红色，输出后立即复位）。所以整体思路是：内核接收到ESC序列字符串后，解析其内容并更改内部的输出模式，于是后续输出的字符就改变颜色。

---

Lab 2: Virtual memory

Lab 2开始难度陡增，个人感觉2和3可能是最难的两个Lab了。也可能是刚开始，一切还都不熟悉，所以感觉比较难。最烧脑的就是虚拟地址和物理地址的转换，以前从来没觉得这块知识很难，但在JOS里这绝对是最难的一块内容！

---

2.1 引导过程简介

因为之前在《操作系统内核Hack：(三)引导程序制作》花了几个月时间详细研究了系统启动过程，所以这一部分驾轻就熟，节约了不少时间。不太了解这部分背景知识的同学，可以看一下本人的《操作系统内核Hack》系列文章，写的应该还算比较清楚。要注意的一点区别就是：JOS采用AT&T汇编语法格式而不是比较流行的NASM，详细区别可以参考《Brennan’s Guide to Inline Assembly》，差别其实不大。

第一阶段引导：JOS的启动方式比较标准，boot文件夹下boot.S首先负责读取内存信息，以Multiboot格式存储在multiboot_info位置。这个信息是留给内核后续使用的，要详细了解Multiboot格式的话请参考Multiboot Specification。之后JOS开始加载GDT描述符，并进入保护模式。进入保护模式之后，迅速进入到C环境进行第二阶段引导。这一点比我之前学习的Linux内核要快很多，在Linux 0.11中这一部分的很多工作都是在汇编环境下完成的。也许是出于快点进入C编程环境，降低学生上手的难度吧，毕竟启动部分的确是非常复杂！

第二阶段引导：进入到boot/bootmain()后开始第二阶段引导。最主要的工作就是：从磁盘上读取内核文件，将控制转移到内核代码。关于如何读取磁盘找到内核并加载到内存，就不细说了，因为很枯燥啊，看看Orange’s读取FAT16的代码有多麻烦就知道了。关于找到内核入口的方式，JOS采取的策略类似于Orange’s，解析ELF文件头，找到内核的第一条指令。而Linux 0.11的方式则是将内核编译为纯二进制，并去掉没用的信息，所以内核的第一个字节就是第一条指令。

进入Kernel：因为前面说了，JOS“过快地”进入了C环境，而有些工作只能用汇编实现。“欠下的账”终究要还，所以内核的entry起始部分（kern/bootstrap.S）又再次进入汇编环境。把欠下的账补上后，才能完全进入C语言的世界。而kern/bootstrap.S要补上的最重要工作就是：设置页表，开启分页机制。下面进入本文的重点，页式管理。

---

2.2 内存分配的本质

谈到内存分配，第一反应就是C语言里的malloc()，以及高级语言C++/Java里的new关键字。可我们现在要写的是系统内核，还没有malloc()库函数（在《操作系统内核Hack》系列里曾讲过，开发内核时是不能随便引用标准库的），更没有高级语言里的new。就在迷茫的时刻，才会思考问题的本质。我们说内存分配时到底在说什么？其实对于内核来说，内存分配就是“随意”地返回一个地址给调用方使用，只要你保证这个地址不被其他人使用，那就是一次成功的内存分配了。所以，我们一般说的不管是JVM也好还是malloc也好，内存分配和释放的消耗其实都是内存管理器复杂管理的代价，如果我们用最最简单的Bump Allocator的话，内存分配的本质真的就像上面说的那样简单、原始！

---

2.3 虚拟地址 vs. 物理地址

现在就来看最为头疼的页式管理吧。这绝对是实验二的最大难点了！哪里是虚拟地址？哪里是物理地址？什么时候会发生转换？cr3以及每一级页表里存的是虚拟还是物理地址？GDB打印的又是什么地址？一个个问题搞得我晕头转向。现在终于有一些“清醒”了，就谈谈我对这些困惑问题的理解：

1. 所有编译器“生成”的都是虚拟地址，例如：int a = &p，通过&p得到的地址就是虚拟地址。
2. 所有内存访问都会发生地址转换，例如：a[i]、*p，这两种形式的解引用都要求变量是虚拟地址。如果是自己手动赋的物理地址，就会导致MMU翻译时找不到对应的页表项而报错。
3. 物理地址只能做二次转换获得，例如：a = PADDR(&p)。这种转换可行的前提是你知道当前页是如何映射的，即页表内容。这在内核中是可以办到的，也是我们在JOS实验二中做的事儿。但是未来你想要在某个用户进程中得到一个变量实际存在哪里了，这几乎是不可能的，因为操作系统已经对你屏蔽了这些东西。
4. cr3里存的是物理地址，而且每一级页表pml4e、pdpe、pde、pte的表项里存的都是物理地址。否则就会出现“死循环”的效果了。假如pml4e[5]里存的是某一pdp表的虚拟地址，那么MMU又要拿着这个虚拟地址重新从pml4e来一遍…… 所以页表的内容类似于：pml4e[1]=0x1000(pdpe) => pdpe[0]=0x2000(pdp) => pde[11]=0x3000……
5. 用GDB打印指针的地址是虚拟地址，但可以通过指定物理地址查看内存。例如，p/x a看到的就是虚拟地址，而x/10x 0x1000查看的就是物理地址0x1000位置的内容。

如果大家修改到那几个walk()函数时可以会有疑问：为什么继续向下一级页表递归时要将页表地址通过KADDR()转为虚拟地址呢？因为每一级页表的walk()函数处理时都有pml4e[i]、pdpe[i]、pte[i]。不要忘记前面说过的，只要解引用就会发生地址转换！硬件逐级递归时是没有这个问题的，而我们的walk()函数是用软件模拟，所以一定要转为虚拟地址再递归！

---

Lab 3: Processes/environments

Lab 3的难度与Lab 2相当，最大难点就是中断（Interrupt）了。这两个Lab中涉及到的内存管理和中断可以说是最核心的知识，挺过这两个Lab后面就一马平川了！既然中断这么重要，那肯定不是三言两语可以说清楚的，强烈建议大家按照JOS的Instruction去实现，并且遇到问题一遍遍调试。这样整个中断的执行流程就会在你脑海里强化记忆，加深理解。

---

Lab 4: Multiprogramming and fork

经过了前面三个Lab的洗礼，Lab 4开始就是按部就班就可以了，个人感觉没有特别难的地方了。Lab 4首先让大家熟悉多核环境，我们要做的就是初始化好多核的运行环境，主要是多个内核栈和对应的TSS配置等。

---

4.1 OS中枢：调度器

OS的调度是由一个Timer发起的，引发中断进入内核态后，调用中断处理函数进行处理。因为JOS的中断过程是由BKL（Big Kernel Lock）保证的，所以中断处理函数运行时“整个世界都清净了”。不管有几个核心，此时世界静止，等待我们进行调度，在返回用户态的前一刻才会放开BKL。中断处理函数可做的事情很多，像简单的RR、复杂的类CFS、有趣的Lottery调度等等，大家尽可以根据自己兴趣去实验各种调度方式。像控制了OS的大脑中枢神经一般，控制一切的感觉还是很爽的！

---

4.2 COW Fork

本Lab的第二个核心就是实现拥有Copy-on-Write能力的Fork。要注意的是因为JOS采取的是Microkernel架构，所以Fork是在用户态配合几个系统调用完成的。因为要遍历进程地址空间决定是否要Copy还是Share，所以Instruction中给出了一种貌似很神奇的办法：顺序遍历一个数组。一直理解得不是很好，个中奥秘还是大家自己去探索吧！

---

4.3 IPC通信

因为JOS的Microkernel架构的缘故，在Lab 5和Lab 6中的FS和网络大量使用IPC通信，所以一定要对IPC有清晰的理解才能做好下两个Lab。其实并不难，IPC接收方调用receive()函数挂起自己，发送方调用send()进行数据通信后，内核唤醒接收方继续处理。

---

Lab 5: File System and Shell

Lab 5的核心就是一个：FS。JOS的FS对Linux的VFS进行了大量简化，最重要的改变就是去掉了inode，直接通过dentry管理文件和元数据。个人觉得，这个改动非常不好！一是因为inode真的太重要了，这个改动却导致了我们失去深入理解它的机会。二就是没了inode加上各种数据结构命名的不同，将JOS的FS部分与Linux的VFS对比学习时会产生很大困惑。强烈推荐大家看一下《Linux Kernel Architecture》之后，做一下实现inode的那个Challenge，具体请参见最后一部分。

---

Lab 6: Network Driver

这是我们的Final Lab，可以选网络驱动、虚拟化和自选题目。因为可能在MIT的原始材料里没有对应，所以就不详细说了。主要目的就是实现一个网络驱动，接收和发送网络包。难度不是很大，但因为是最终的Lab所以给出的Hint比较少，需要认真读Instruction和Intel的手册，总体上还是蛮有趣的！

---

福利：Challenges You Cannot Miss

本节给大家推荐一些我认为非常不错的Challenge，当然了，我没全做出来。因为有的真的工作量挺大的，也因为时间真的太紧了，而老师给Challenge的分数权重又比较低。但我觉得Challenge真的挺重要的，因为做正规题目时有很多Instruction和Hint，有时你做完后并不是理解的很透彻。而Challenge则完全只有挑战内容，没有太多的帮助。所以如果有时间多做一些的话，真能让你学的更扎实、更上一层楼！

• Lab 2 - Challenge 2! Homemade Debugger (强烈推荐)：通过这个Challenge你也许会开始思考GDB，曾经理所当然的工具，它内部究竟是如何实现的呢？要想实现简单的断点和内存查看其实不太难，难的是像GDB一样根据编译器给出的调试信息进行反汇编。
• Lab 2 - Challenge 4! General Memory Allocator (Slab)：题目要求实现一个能分配4K的整数倍的通用内存管理器，但个人觉得实现成Slab也许收获更大，但可能难度也更高。如果你真的实现了的话，后面很多Lab要给内核数据结构分配内存时就都可以用你自己的通用管理器了，真爽！
• Lab 3 - Challenge 3! Faster System Call (Sysenter/Sysexit)：现在Linux中只要是环境允许的话，就会用这种所谓的快速系统调用。因为与传统的将所有上下文信息都压栈保存的方式有很大不同，所以要实现的话还是有些工作量的。
• Lab 4 - Challenge 1! Fine-grained Lock：JOS中为了简化，用的是BKL（Big Kernel Lock），只要进入内核态就一把大锁直接锁死，等回到用户态再放开。这就极大简化了多CPU时，内核数据结构的并行访问问题，当然也降低了并行性。BKL是Linux的技术债务，虽然并未完全移除，但在后续代码中是绝对不会使用它了。
• Lab 4 - Challenge 2! Scheduling Policy (强烈推荐)：JOS只要求我们实现的是最简单的RoundRobin策略，这个Challenge让我们实现更有趣的调度，比如Lottery调度。利用随机数决定下一个运行的进程，允许进程具有不同的优先级的同时又无需做Bookkeeping，真是巧妙！具体可以参考《Three Easy Pieces》的精彩介绍！要注意的是：随机数生成器也要我们自己实现，因为内核里没有类似rand()这种函数，Wiki一下你会发现奇妙的东西。
• Lab 4 - Challenge 6! Share-Everything Fork (Threading!) (强烈推荐)：JOS只要求实现了进程调度，通过这个Challenge你会Wow，原来这就是Thread啊！具体请参考Linux内核的clone()函数。
• Lab 5 - Challenge 1! Interrupt-driven IDE Driver：JOS目前用的是最简单的PIO（Programming I/O）方式与磁盘交互，本Challenge要实现中断式的方式，更贴近现实世界里的Linux。
• Lab 5 - Challenge 2! Page Cache Eviction：默认Page Cache是没有Evict功能的，这里我们可以实现一个简单的替换算法，例如Second-Chance。
• Lab 5 - Challenge 3! Journaling (强烈推荐)：要为JOS的FS加上Journaling功能，工作量不是特别大（相比下一道Challenge），但需要对Ext3有比较清晰的了解，又是《Three Easy Pieces》，讲解的真的非常棒！
• Lab 5 - Challenge 4! inode Implementation (强烈推荐)：这道题可谓是我做过的Challenge里工作量之最了，修改了将近15个文件，又新增了用户空间的测试程序，但收获也是巨大了！做完此题，你会对dentry、inode、file三大VFS核心对象有彻底清晰的认识，对in-memory和on-disk数据结构有全新的了解，对JOS的FS和Linux的VFS有充分的对比，此题真的不容错过！推荐《Linux Kernel Architecture》对应VFS几章精彩的讲解，这一部分的精彩程度真的完爆《Understanding the Linux Kernel》。
• Lab 5 - Challenge 5! Implement Unix-style exec：不借助内核帮助，在parent和child进程的用户空间里实现exec真是挺麻烦的，因为你已经进入child用户空间了，还要为child真正的ELF文件指定的main做准备工作再跳转，这些工作正常来说都是在内核态中完成的。至少我最后也没做出来……
• Lab 5 - Challenge 6! Implement mmap-style Memory-mapped Files：mmap的实现到了最后我也是云里雾里的，一定要抽时间好好理清一下。