C7

just a test

准备首先到手几个文件 解压出文件系统后发现里面有个shell脚本gen_cpio.sh来生成core.cpio，每次我们修改了内核的启动init后我们就要重新打包一份core.cpio，我们可以直接将他写进我们的启动脚本里面 #!/bin/bashcd core./gen_cpio.sh core.cpiomv core.cpio ../core.cpiocd ..qemu-system-x86_64 \-m 128M \-kernel ./bzImage \-initrd ./core.cpio \-append 'console=ttyS0 root=/dev/ram rw oops=panic panic=1 quiet kaslr' \-netdev user,id=t0, -device e1000,netdev=t0,id=nic0 \-gdb tcp::123 \-nographic \ 接着观察下init #!/bin/shmount -t proc proc /procmount -t sysfs sysfs /sysmount -t devt ...

任务实现backtrace命令 分析我们需要查询STAB（Symbol TABLE）的知识来完成此内容 在kdebug.c中添加如下片段来获取函数行号： stab_binsearch(stabs, &lline, &rline, N_SLINE, addr);info->eip_line = stabs[lline].n_desc; 在monitor.c中添加backtrace函数 intbacktrace(int argc, char **argv, struct Trapframe *tf){ int* ebp = (int *)read_ebp(); cprintf("Stack backtrace:\n"); while(ebp){ cprintf(" ebp %08x",ebp); cprintf(" eip %08x",*(ebp+1)); cprintf(" args"); c ...

任务完成mon_backtrace()函数 分析我们可以利用课程提供给我们的read_ebp()函数来获取此时的ebp，不过要注意的是他返回的是int类型，接下来就是简单的指针操作了。 intmon_backtrace(int argc, char **argv, struct Trapframe *tf){ int* ebp = (int *)read_ebp(); cprintf("Stack backtrace:\n"); while(ebp){ cprintf(" ebp %08x",ebp); cprintf(" eip %08x",*(ebp+1)); cprintf(" args"); cprintf(" %08x",*(ebp+2)); cprintf(" %08x",*(ebp+3)); cprintf(" %08 ...

任务判断一下操作系统内核是从哪条指令开始初始化它的堆栈空间的，以及这个堆栈坐落在内存的哪个地方？内核是如何给它的堆栈保留一块内存空间的？堆栈指针又是指向这块被保留的区域的哪一端的呢？ 分析1.首先判断操作系统内核是从哪条指令开始初始化它的堆栈空间前面以及分析过boot.S和main.c文件的运行过程，这个文件中的代码是PC启动后，BIOS运行完成后，首先执行的两部分代码。但是它们并不属于操作系统的内核。当main.c的最后一条指令讲处理器的控制权交给entry.S时，此时才真正进入操作系统内核。其实我们能发现，在进入entry之前，并没有对于%esp，%ebp寄存器的内容的修改，所以在bootmain中并没有初始化堆栈空间的语句。 下面进入entry.S，在entry.S中我们可以看到它最后一条指令是要调用i386_init()子程序。这个子程序位于init.c文件之中。在这个程序中已经开始对操作系统进行一些初始化工作，并且自重进入mointor函数。可见到i386_init子程序时，内核的堆栈应该已经设置好了。所以设置内核堆栈的指令就应该是entry.S中位于 call i386_i ...

任务我们丢弃了一小部分代码—即当我们在printf中指定输出”%o”格式的字符串，即八进制格式的代码。尝试去完成这部分程序。 分析在这个练习中我们首先要阅读三个源文件之间的代码，弄清楚他们三者之间的关系。他们是/kern/printf.c，/kern/console.c, /lib/printfmt.c 首先大致浏览三个源文件，大致观察到： printf.c中的cprintf调用了vcprintf，然后vcprintf调用了printffmt.c中的vprintfmt。 printf.c中的putch调用了console.c中的cputchar，cputchar调用了cons_putc。 printfmt.c中的某些程序也依赖于cputchar。 所以printf.C，printfmt.c的功能依赖于console.c的功能。所以我们先探讨下console.c。 /kern/console.c这个文件中定义了把一个字符显示到console上，即我们的显示屏上，里面包括了很多对IO端口的操作。 其中我们最感兴趣的cputchar函数。从注释中我们知道这个是最高处的console的IO ...

任务使用Qemu和GDB去追踪JOS内核文件，并且停止在movl %eax, %cr0指令前。此时看一下内存地址0x00100000以及0xf0100000处分别存放着什么。然后使用stepi命令执行完这条命令，再次检查这两个地址处的内容。确保你真的理解了发生了什么。如果这条指令movl %eax, %cr0并没有执行，而是被跳过，那么第一个会出现问题的指令是什么？我们可以通过把entry.S的这条语句加上注释来验证一下。 分析首先我们断点到0x10000C处，因为我们在之前的练习中已经知道了，0x10000C是内核文件的入口地址。然后我们从这条指令开始一步步运行，直到碰到movl %eax, %cr0指令。在这条指令运行之前，地址0x00100000和地址0xf0100000两处存储的内容是： 可见两地址处的值是不一样的。 当执行完movl %eax, %cr0后，在查看两个位置： 我们会发现两处存放的值已经一样了！ 可见原本存放在0xf0100000处的内容，已经被映射到0x00100000处了。 第二问需要我们把entry.S文件中的%movl %eax, %cr0这句话注释 ...

任务在这个练习中，我们将尝试使用GDB的x命令（查看内存命令）。 x/Nx ADDR。这个指令将打印出从ADDR地址开始之后的N个字的内容。重启一下Qemu。在Bios进入boot loader之前，内存地址0x00100000处8个字的内容，然后进入boot loader运行到内核开始处停止，再看下这个地址处的值。为什么二者不同？第二次这个内存处所存放的值的含义是什么？ 分析在进入boot loader之前，从内存地址0x00100000处开始之后8个字的内容为： 在进入kernel那一刻之前，从内存地址0x00100000处开始之后8个字的内容为： 为什么会产生这种变化，因为bootmain函数在最后会把内核的各个程序段送入到内存地址0x00100000处，所以这里现在存放的就是内核的某一个段的内容，由于程序入口地址是0x0010000C，正好位于这个段中，所以可以推测，这里面存放的应该是指令段，即.text段的内容。

任务再一次追踪一下boot loader的一开始几句指令，知道第一条满足如下条件的指令处： 当我修改了boot loader的链接地址，这个指令就会出现错误。 找到这样的指令后，把boot loader的链接地址修改一下，我们要在boot/Makefrag文件中修改它的链接地址，修改完成后运行 make clean， 然后通过make指令重新编译内核，再找到那条指令看看会发生什么。 最后别忘了改回来。 分析这道题希望我们修改boot loader的链接地址，在Lab 1中，作者引入了两个概念，一个是链接地址，一个是加载地址。链接地址可以理解为通过编译器链接器处理形成的可执行程序中指令的地址，即逻辑地址。加载地址则是可执行文件真正被装入内存后运行的地址，即物理地址。 那么在boot loader中，由于在boot loader运行时还没有任何的分段处理机制，或分页处理机制，所以boot loader可执行程序中的链接地址就应该等于加载地址。在Lab中作者说，BIOS默认把boot loader加载到0x7C00内存地址处，所以就要求boot loader的链接地址也要在0x7C00处。b ...

检查$ checksec main[*] '/home/C7/\xe6\xa1\x8c\xe9\x9d\xa2/tw/bookwriter/main' Arch: amd64-64-little RELRO: Full RELRO Stack: Canary found NX: NX enabled PIE: No PIE (0x400000) FORTIFY: Enabled$ strings libc_64.so.6 | grep GNUGNU C Library (Ubuntu GLIBC 2.23-0ubuntu5) stable release version 2.23, by Roland McGrath et al.Compiled by GNU CC version 5.4.0 20160609. GNU Libidn by Simon Josefsson 最近在学house_of_orange技术。这道题算是自己的第一次实践，但是本地能通，远程不知道为什么不行。 ...