思路 被这个实验折磨了两天，可能是2024新出的一个实验内容，网上资料少，参考了一篇仅有的博客，吭哧吭哧分析出来了个大概吧…在此记录一下，以便帮助有需要的人。 attack xv6的ans只有几行代码，根据实验描述，大概能猜到是secret程序结束之后，attack程序复用了它的物理内存，然后读取之前写入内存中的密码。难点在于我们如何定位到那段内存。 在开始之前直接先给出ans，可以看到代码是很简单的： #include "kernel/types.h" #include "kernel/fcntl.h" #include "user/user.h" #include "kernel/riscv.h" int main(int argc, char *argv[]) { // your code here. you should write the secret to fd 2 using write // (e.g., write(2, secret, 8) char *end = sbrk(17*PGSIZE); end += 16 * PGSIZE; write(2, end+32, 8); exit(1); } 下面说说实验思路，实验目的是找到被复用的物理内存，而内核的物理内存使用栈式链表管理（kalloc.c），secret程序通过kalloc从栈顶取内存页来使用，程序结束后通过kfree将这些内存页放回栈顶。到attack运行的时候同样使用kalloc从栈顶取内存页，因此就给了attack复用物理内存的机会。 值得注意的是，secret分配内存时这些页的出栈顺序，不一定与attack分配内存时的出栈顺序相同，比如secret分配页的顺序为1,2,3，归还的顺序为2,3,1，那么此时栈顶到栈底的页分别为1,3,2，当attack来分配的时候，拿到页的顺序就是1,3,2。因此核心在于分析程序运行时物理内存页的分配以及回收顺序，才能知道attack应该到哪块内存中获取密码。 fork secret 我们从attacktest中的第一个fork开始分析。 fork调用了allocproc来创建proc，allocproc中首次使用了kalloc为p->trapframe分配一页物理页。 接着allocproc调用proc_pagetable创建页表，其中，先调用uvmcreate使用kalloc为根页表分配一页： 然后为trampoline和p->trapframe建立映射，这两页在最虚拟内存的最高地址处，处于同一个三级页目录（xv6使用sv39，即三级页表），因此又kalloc了两页，分别对应一页二级页表、一页三级页表： 因此allocproc一共创建了4页（trapframe、三级页表）。 回到fork中，由于此时xv6的fork还没实现copy on write特性，因此需要把父进程用户内存中的内容（用户内存即stack、heap这些低地址内存，不包括trapframe、trampoline）使用uvmcopy全部复制到子进程中。此时父进程用户内存占用此时为4页，因此子进程也复制了这4页进来，由于这4页位于虚拟内存中的低地址，其二级三级页表与trapframe/trampoline的都不一样，所以还会创建两页分别用于二级三级页表，一共kalloc了4+2=6页（为什么是4页具体原因在后面分析exec时会揭晓）。 综上，fork一共分配了4+6=10页。 exec secret 然后就是执行exec： 在exec的实现中，会使用proc_pagetable创建新的页表来替换旧页表（这个也好理解，因为exec目的就是替换整个程序镜像，相当于从头开始执行一个新的程序，之前程序的相关内容全部丢弃）。根据之前的分析，proc_pagetable会分配3页。 接着，exec遍历elf文件的program header，将所有LOAD段加载进内存中。具体是通过uvmalloc分配物理内存，loadseg将段加载进内存。xv6程序的elf文件包含两个LOAD段，data段和text段，可以通过readelf看一下： 这两个段分别加载到虚拟内存的第0页和第1页中。同理，这两页属于低地址的用户内存，需要2页（二级页表、三级页表）+2页来分别存放这两个段。 接着，exec为用户栈分配内存： 这里的USERSTACK值为1，因为xv6固定用户栈大小为一页，后面的+1多出的一页用于page guard，便于栈溢出的处理。另外栈是紧挨着data段和text段之后分配的，他们属于同一个三级页表，不需要额外分配页表，因此栈分配一共分配了2页 exec的最后，还调用了proc_freepagetable来释放旧页表和旧用户内存： s’d’s 其中的两个uvmunmap释放pte映射（避免后续uvmfree的时候意外释放trampoline和trapframe的物理内存），并不释放物理页，因为trampoline是整个操作系统共享的不需要释放，而trapframe是用户态和内核态转换时的用到的存储区域，十分重要，同样不会释放（关于trapframe和trampoline的详细说明可以查阅book-riscv）。最后的uvmfree则是释放旧页表占用的内存（5页）以及用户内存（4页），共9页。 ...

primes 比较容易想到的是递归的做法：主进程生产2 ~ 280这些自然数通过管道传输给子进程，子进程读取并将第一个数作为素数输出，剩下的数用该素数作为筛子来筛选，没有被筛除的数就输入管道，输入给下一个子进程，下一个子进程重复上述步骤。 #include "kernel/types.h" #include "user/user.h" void sieve(int in_fds[2]) __attribute__((noreturn)); int main(int argc, char *argv[]) { int fds[2]; pipe(fds); if (!fork()) { sieve(fds); } close(fds[0]); for (int i = 2; i <= 280; i++) { write(fds[1], &i, sizeof(int)); } close(fds[1]); wait(0); exit(0); } void sieve(int in_fds[2]) { close(in_fds[1]); int p, num; int fds[2]; // read base if (!read(in_fds[0], &p, sizeof(int))) { exit(0); } // create next sieve printf("prime %d\n", p); pipe(fds); if (!fork()) { sieve(fds); } // output to next sieve close(fds[0]); while (read(in_fds[0], &num, sizeof(int))) { if (num % p == 0) continue; write(fds[1], &num, sizeof(int)); } close(in_fds[0]); close(fds[1]); wait(0); exit(0); } 但是我这边输出显示乱码： 调试发现是sieve中创建管道的时候失败，进一步发现是将文件描述符消耗完了（xv6中限制文件描述符最大大概为14、15这样）。为什么会消耗完呢： 结合图示，每个进程创建两个文件描述符，关闭其中一个（读管道fds[0]），fork一个新的sieve子进程，开始处理数据，并且只有处理完数据之后才会关闭另一个（写管道fds[1]），当创建新进程的速度大于进程处理数据的速度时，即打开文件的速度大于关闭的速度，迟早会超出文件描述符数量限制，新的进程就无法再创建管道，因此程序跑不下去。 解决方法是用主进程来管理这些管道文件描述符，因为主进程只关注两两进程之间通信使用到的管道，其它管道一律关闭，因此限制了打开文件描述符的数量，具体方式是将递归变更为迭代的方式来创建子进程： 主进程先创建一个生产自然数的进程以及管道，用于生产自然数，其对外暴露一个读管道rfd。随后，主进程创建工作进程以及管道fds，将读管道rfd和写管道fds[1]交给该子进程，子进程从rfd读入数据、筛选数据、数据写入fds[1]。在主进程中将会关闭rfd和fds[1]，将fds[0]作为下一个进程的rfd，创建下一个工作子进程….重复上述步骤。 ...

穿越时空的旅行 异常响应机制及CTE 实现异常响应机制 我们要实现操作系统的自陷功能，虽然中断的大致原理和流程上课都讲过，但不同操作系统有着不同的具体设计，因此在这之前有必要结合文档与源码过一遍我们框架代码中“异常响应机制”的流程 riscv对于中断与异常提供了各种令人眼花缭乱的CSR控制状态寄存器，我们这里涉及到的有： mtvec寄存器 - 存放了发生异常时处理器需要跳转到的地址 mepc寄存器 - 存放发生异常的指令地址，用与异常处理返回时能回到原本程序执行的位置 mstatus寄存器 - 存放处理器的状态 mcause寄存器 - 存放异常的种类 另外根据文档中提到 首先当然是对R的扩充, 除了PC和通用寄存器之外, 还需要添加上文提到的一些特殊寄存器 所以我们先给处理器添加上述的几个CSR typedef struct { word_t mcause; vaddr_t mepc; word_t mstatus; word_t mtvec; } riscv64_CSRs; typedef struct { word_t gpr[32]; vaddr_t pc; riscv64_CSRs csr; } riscv64_CPU_state; 定义好了需要到的寄存器后，接下来我们就结合nanos-lite的运行来分析中断响应流程吧～在此之前需要再次明确一下模拟器的各层的关系：am是硬件层（确切地说是抽象硬件，对操作系统屏蔽了架构的差异），nanos-lite是操作系统层。我们从nanos-lite的入口，main函数看起，其中中断相关我们只需要关注init_irq以及yield，先回忆一下，还记得文档说的那句话吗？ 我们刚才提到了程序的状态, 在操作系统中有一个等价的术语, 叫"上下文". 因此, 硬件提供的上述在操作系统和用户程序之间切换执行流的功能, 在操作系统看来, 都可以划入上下文管理的一部分. init_irq里调用的cte_init，其实就是操作系统向硬件注册事件发生（如中断）的回调函数do_event，这个回调函数就是真正把异常交给操作系统处理的地方（要与异常处理入口函数区分开来），其中的参数为事件和相关的程序上下文。那么这个回调函数什么时候被调用呢，显然是异常发生的时候。 我们接着查看cte_init的代码，其功能简单地说就是保存异常处理入口函数地址，以及保存用户回调函数即上述的do_event，以便异常处理过程中时调用这个用户回调函数。其中异常处理入口函数是__am_asm_trap，这个函数在trap.S这个文件中用汇编语言实现，暂时不管，先接着看流程。 接下来在main函数的最后调用了yield，如果说init_irq描述如何处理异常，那么yield就是真正触发了一个异常（自陷），并进入之前注册的异常处理函数进行异常处理。yield只有两句汇编指令 li a7, -1 ecall 将异常种类存放到a7寄存器中，以及发起自陷，其中ecall会使得程序流程转到之前注册的异常处理入口函数中去执行，即__am_asm_trap，这里就得分析一下这个函数都干了些什么了： __am_asm_trap: ... jal __am_irq_handle ... mret 目前只关注运行流程，多余的代码先去除，__am_asm_trap简单来说是提供了统一的异常入口地址，主要作用是将csr和gpr的内容作为参数调用__am_irq_handle并在其返回后把csr和gpr的新值再存回去（值得一提的是，csr和gpr作为cpu的寄存器，am将他们包装在上下文结构中传给了操作系统，而不是让操作系统直接访问cpu，体现了处处都是抽象和屏蔽的艺术）。__am_irq_handle这个函数也是定义在抽象硬件层(am)中的，通过判断程序上下文内容（比如在riscv-nemu中通过分支mcause的值）来构造事件，最终将事件和上下文一并通过回调函数传给操作系统，开始真正的异常处理….至此从异常注册到异常触发及响应的流程分析就结束了，如果说PA3之前的工作还没对这些抽象硬件、操作系统层等形成认知，或者到了PA3这个部分依然存疑，建议一定要好好做这一小节的内容并去认真体会它是如何设计的，因为确实值得。 若理解了流程，剩下的填代码环节就是顺便的事情了。首先实现几条指令，csr的读写指令和ecall指令 INSTPAT("??????? ????? ????? 001 ????? 11100 11", csrrw , I, R(dest) = CSR(imm); CSR(imm) = src1); INSTPAT("??????? ????? ????? 010 ????? 11100 11", csrrs , I, R(dest) = CSR(imm); CSR(imm) |= src1); INSTPAT("0000000 00000 00000 000 00000 11100 11", ecall , I, ECALL(s->dnpc)); 其中两个新宏CSR, ECALL如下： ...

其他资料： https://github.com/riscv-non-isa/riscv-asm-manual/blob/master/riscv-asm.md http://riscvbook.com/chinese/RISC-V-Reader-Chinese-v2p1.pdf RTFM 运行第一个客户程序 第一个客户程序即文档所说的dummy.c，键入命令后，会将dummy.c编译成基于rv64指令的二进制格式文件（后缀名为 .bin），作为nemu模拟器的镜像文件（img_file） make ARCH=$ISA-nemu ALL=dummy run 实现指令 首先查看反汇编结果，看看需要实现哪些指令 0000000080000000 <_start>: 80000000: 00000413 li s0,0 80000004: 00009117 auipc sp,0x9 80000008: ffc10113 addi sp,sp,-4 # 80009000 <_end> 8000000c: 00c000ef jal ra,80000018 <_trm_init> 0000000080000010 <main>: 80000010: 00000513 li a0,0 80000014: 00008067 ret 0000000080000018 <_trm_init>: 80000018: ff010113 addi sp,sp,-16 8000001c: 00000517 auipc a0,0x0 80000020: 01c50513 addi a0,a0,28 # 80000038 <_etext> 80000024: 00113423 sd ra,8(sp) 80000028: fe9ff0ef jal ra,80000010 <main> 8000002c: 00050513 mv a0,a0 80000030: 00100073 ebreak 80000034: 0000006f j 80000034 <_trm_init+0x1c> 通过查询手册，可以知道li ret等指令都是伪指令，比如第一条指令 80000000: 00000413 li s0,0 其十六进制内容为0x00000413，对应二进制为0000 0000 0000 0000 0000 0100 0001 0011，查询手册可知其为addi指令，而当伪指令li中的立即数小于4096时，的确会被编译器展开为addi指令，因此目前可以确定，反汇编结果的右边的指令只是为了方便阅读（生成反汇编指令的代码在disasm.cc中），我们在实现指令功能时，只需要看左边的十六进制内容即可 按照框架和文档提示，以及根据手册查询每条指令干了什么，然后填写代码即可 enum { TYPE_I, TYPE_U, TYPE_S, TYPE_J, TYPE_N, // none }; #define immJ() do { *imm = SEXT(( \ (BITS(i, 31, 31) << 19) | \ BITS(i, 30, 21) | \ (BITS(i, 20, 20) << 10) | \ (BITS(i, 19, 12) << 11) \ ) << 1, 21); Log(ANSI_FG_CYAN "%#lx\n" ANSI_NONE, *imm); } while(0) static void decode_operand(Decode *s, int *dest, word_t *src1, word_t *src2, word_t *imm, int type) { // ... switch (type) { // ... case TYPE_J: immJ(); break; } } static int decode_exec(Decode *s) { // ... INSTPAT("??????? ????? ????? 000 ????? 00100 11", addi , I, R(dest) = src1 + imm); INSTPAT("??????? ????? ????? ??? ????? 11011 11", jal , J, s->dnpc = s->pc; s->dnpc += imm; R(dest) = s->pc + 4); INSTPAT("??????? ????? ????? 000 ????? 11001 11", jalr , I, s->dnpc = (src1 + imm) & ~(word_t)1; R(dest) = s->pc + 4); // ... return 0; } 程序，运行时环境与AM 实现字符串处理函数 根据前面的铺垫，这部分比较简单，就不贴代码了，只需要： ...

note: 基于riscv64，不适配riscv32 RTFSC 优美地退出 make run启动nemu后直接输入q退出，得到如下最后一行的错误 Welcome to riscv32-NEMU! For help, type "help" (nemu) log Unknown command 'log' (nemu) q make: *** [/home/ubuntu/ics2022/nemu/scripts/native.mk:38: run] Error 1 是由于is_exit_status_bad函数返回了-1，main函数直接返回了此函数返回的结果，make检测到该可执行文件返回了-1，因此报错。通过分析该函数得到解决方案：在输入q中途退出nemu后，将nemu_state.state设成NEMU_QUIT即可 // nemu/src/monitor/sdb/sdb.c void sdb_mainloop() { ... int i; for (i = 0; i < NR_CMD; i ++) { if (strcmp(cmd, cmd_table[i].name) == 0) { if (cmd_table[i].handler(args) < 0) { if (strcmp(cmd, "q") == 0) { nemu_state.state = NEMU_QUIT; // set "QUIT" state when q } return; } break; } } if (i == NR_CMD) { printf("Unknown command '%s'\n", cmd); } } } 此时再通过make run运行后中途键入q命令退出模拟器将不会再报该错误 简易调试器 单步执行 si [N] 第一步，在cmd_table注册一条命令si static struct { const char *name; const char *description; int (*handler) (char *); } cmd_table [] = { { "help", "Display information about all supported commands", cmd_help }, { "c", "Continue the execution of the program", cmd_c }, { "q", "Exit NEMU", cmd_q }, { "si", "Continue the execution in N steps, default 1", cmd_si }, /* TODO: Add more commands */ }; 第二步，编写cmd_si，即si具体要执行的东西 ...