简介《深入理解计算机系统》第三版配套实验包是一份面向计算机系统学习者的实践资源适合正在阅读原书或准备系统掌握底层原理的读者。实验包围绕书中经典实验展开覆盖汇编语言、内存管理、缓存模拟、进程控制、编译器构造与安全攻防等核心主题能帮助学习者把抽象理论落到真实可运行的C程序与实验环境中。资源为rar压缩包共145个文件约1.94MB以C源码、PDF文档、txt说明文本、头文件、makefile构建脚本及Shell脚本为主既包含实验代码和辅助工具也有配套文档与操作提示便于对照学习和环境搭建目前已有1602人学习下载。包内可以看到二进制炸弹拆除、缓冲区溢出攻防、Shell实现、缓存模拟等典型CSAPP实验场景能支撑从底层逆向到系统编程的多层次练习配合pdf与txt资料还能快速理解实验要求、掌握调试与验证思路是一份值得系统研读的CSAPP实践合集。1. CSAPP 第三版实验为什么值得你花一个月重做一遍我第一次跑 Data Lab 而不是在《深入理解计算机系统》第三版上划线时才意识到这本教材的精气神全在配套实验里。CSAPP 第三版实验包是一组让“计算机系统”从抽象变成可复现事故现场的资源位运算、缓冲区溢出、缓存模拟、堆分配器、Shell 编程每个 lab 都对应书里一章的核心机制。秋招季很多系统岗位的问答素材实际就是从这套实验抽出来的变形题。适合刚读完教材却写不出代码的初学者也适合想补底层功底的开发老手。一个实验完整跑通的收获抵得上反复看书三遍。2. 环境搭建先解决 Ubuntu 里的工具链再碰实验包2.1 为什么最终选择 Linux评分脚本和内存检查器只认这套生态这套实验自带 makefile 和 perl 评分驱动设计初衷是 Linux 环境。Windows 上即便用 WSL也会遇到/tmp权限、符号链接、32 位库缺失等一连串问题macOS 上更麻烦gcc实际是clang部分汇编代码和-m32编译参数的行为不一致bomb 和 attack 实验反汇编出来的指令风格也会有差异。我一般建议装一个 Ubuntu 22.04 或 20.04 的虚拟机分配 4GB 内存、两个以上 CPU 核心就够了。选 22.04 是因为它自带的 gcc 是 11.x支持 C11编译老实验包没有任何问题20.04 的 gcc 9.x 也完全能跑。不要一上来就去追最新 24.04 的 gcc 13遇到个别 lab 的驱动源码报编译警告升级成错误那种一次配置半小时的体验很劝退。有些实验需要编译 32 位版本比如早期版本的 data lab 驱动或者你想用-m32观察指针大小的变化。单纯装gcc不够还需要gcc-multilib这个库否则链接阶段直接报bits/libc-header-start.h: No such file or directory之后你再怎么改 C 代码都白搭。2.2 解压后的实验目录与各个实验的作用下载到的实验包通常是一个 tar.gz 压缩文件解压后能看到若干独立目录。一般包括 data、bomb、attack、cache、malloc、shell、proxy 这几组。data 对应第二章信息的位运算与浮点数表示bomb 是汇编逆向通关attack 是栈溢出与 ROP 注入cache 是缓存模拟器和矩阵转置优化malloc 是实现动态内存分配器shell 是写一个微型 Unix Shellproxy 是写一个并发 HTTP 代理。每个 lab 目录内部结构高度一致一个Makefile、一份讲义writeup、一个评分驱动脚本或二进制、若干.c/.h骨架源码以及traces或target这类附属数据目录。拿到压缩包后我习惯先用tar -xzf解压到~/csapp-labs下然后逐个目录执行make目的不是立刻写代码而是确认每个 lab 的原始构建链路是通的。如果连默认代码都编不过先检查是不是 gcc 版本或缺少 32 位库别急着改实验代码。2.3 一条命令装齐工具链并自检在 Ubuntu 里执行以下命令sudo apt update sudo apt install -y build-essential gcc-multilib gdb valgrind gcc --version | head -1 make --version | head -1 gdb --version | head -1build-essential负责安装 gcc、make 和基础头文件gcc-multilib提供 32 位编译支持gdb是 bomb lab 的必备调试器valgrind在 malloc lab 里检查内存错误比你自己盯着指针找省力得多。最后三条--version命令是自检确认工具链进入 PATH。装完工具链后进入 data lab 目录先执行一次make。如果看到生成btest、dlc这类可执行文件且无报错说明环境合格。常见的一个坑是某些驱动脚本用/usr/bin/env python调 Python 2但新版 Ubuntu 只有 Python 3此时需要把脚本第一行的python改成python3或者用ln -s /usr/bin/python3 /usr/bin/python做兼容但后者容易引起系统级混乱我更推荐直接改实验脚本第一行。3. Data Lab 从 bits.c 到 btest位约束、浮点坑与评分机制3.1 dlc 这个“位操作白名单”到底在检查什么Data Lab 的核心文件是bits.c里面有十几个函数等着你填空。每个函数顶部都有注释说明允许使用的运算符还有一条铁律不能使用if、while、for、、||、?:不能使用超过0xff的常量。这套限制初看很玄学其实是逼着你用位运算表达逻辑分支。dlc是官方自带的数据实验检查器它并不是编译器而是一个语法与操作符的静态检查工具。执行./dlc bits.c如果不输出任何报错说明你的代码没有越界使用运算符。常见的违规行为比如想判断一个整数是否为正数时写出了x 0dlc 会直接报illegal operator。我把 dlc 当作第一道闸门写完一个函数就跑一次避免积累一堆错误后再排查。它不会检查逻辑正确性只检查“白名单”约束。举个例子实现“判断数值是否为负数”的逻辑int isNegative(int x) { return !!(x 31); }逻辑说明算术右移保留了符号位负数右移后结果是0xffffffff再通过!!双重取反变成 0/1。参数说明这里不能用x 0因为不在允许运算符列表里x 31在负数场景下依赖编译器对算术右移的实现这本实验明确要求使用算术右移所以可以依赖这个行为。dlc通过后下一步是btest做功能验证./btest -f isNegative-f参数指定只测某个函数会输出函数名、测试用例和实际结果如果不匹配会明确给出ERROR。整个文件的所有题目跑完执行./driver.pl它会调用 dlc 获取风格分再调用 btest 获取正确性分最后汇总一个总评。评分脚本的权重里正确性占大头风格分看代码行数是否够短所以别写太啰嗦。3.2 从零开始跑通一道位运算题的完整流程以logicalShift为例要求实现逻辑右移但不能直接用。我一般先写一个最朴素的版本int logicalShift(int x, int n) { int mask ~(((1 31) n) 1); return (x n) mask; }逻辑说明算术右移会在高位补符号位所以要构造一个低32 - n位全为 1 的掩码把符号扩展位清掉。1 31得到最高位为 1、其余为 0 的数算术右移n位后前面n1位都是 1再左移一位让第n位变为 0最后取反得到口罩。参数说明n的范围在输入中限定为 0 ~ 31所以不需要处理n32的极端情况。写完立即跑./dlc bits.c ./btest -f logicalShift我在前几次练习时吃过一个亏dlc是通过了但btest报错原因是1 31是未定义行为gcc 在优化级别高时有把所有左移符号位场景改写成随机值的风险。后来我改成1 31前先加unsigned强转或者直接用0x80000000常量但常量超过0xff限制于是采用方案int logicalShift(int x, int n) { int sign (x n) ~((1 31) n); return sign; }这个思路更稳妥x n保留符号位扩展再与一个“清除高位冗余”的掩码相与避免未定义左移。实际开发中这类“编译器优化破坏位运算直觉”的问题很常见Data Lab 就是让你提前体验。3.3 浮点题目的隐藏坑类型转换与舍入Data Lab 后半部分要求处理float的位级表示但函数入参是unsigned你要自己解析符号位、阶码和尾数不能直接做浮点运算。比如实现float_i2f把int转成float的位模式。第一步要提取符号位然后算绝对值再找最高位的 1 来确定阶码偏移。参数设计上关键变量有三个sign占 1 位exp占 8 位frac占 23 位。舍入是这里最容易翻车的地方不只是简单截断而是要考虑“向偶数舍入”。常见解法是先右移丢弃多余尾数位再检查丢弃部分的最高位以及保留部分的最低位决定是否需要加一。每次做完这种操作用btest -f float_i2f单独验证一大圈边界值尤其是0x7fffffff、0x80000000、幂次方边界等。另一个坑是float_twice这类题看起来简单的“指数加一”其实还要处理三种特殊情况阶码全 0 时应该把尾数左移一位阶码全 1 时直接原样返回无穷大和 NaN 也要保持原样。我在第一次实现时只处理了正常数结果btest在边界输入上报了十多个错误。这类边界判断正是教材第二章“浮点数表示”里讲的内容只是实验把它变成了你必须手写的逻辑。4. Bomb 与 Attack Lab从反汇编到栈破坏的实操链路4.1 GDB 断点三板斧break、disassemble、x/wBomb Lab 是个二进制炸弹文件里面包含 6 个 phase每个 phase 读取一行字符串正确则通过错误则引爆炸弹。动手前先objdump -d bomb看反汇编然后用 gdb 加载可执行文件gdb bomb (gdb) break phase_1 (gdb) run程序会停在第一个 phase 的入口此时执行disassemble能看到这一小段汇编。phase_1通常先比较两个字符串地址最常见的形式是调用strings_not_equal然后根据返回值决定是否调用explode_bomb。参数说明break phase_1是在函数入口下断点run启动程序gdb 会在第一个断点暂停。继续用x/s 0x402400查看内存中某个地址里的字符串x是“查看内存内容”的命令/s表示按字符串格式输出。看到目标字符串后把它写进答案文件然后quit重启 bomb输入该字符串进入下一阶段。三条我常用的 GDB 指令组合(gdb) break *0x4012ab (gdb) x/20i $rip (gdb) x/wx $rspbreak *0x4012ab指的是在绝对地址下断点适合对付那些没有符号的中间函数x/20i $rip反汇编当前指令指针附近的 20 条指令x/wx $rsp查看栈顶的 32 位值在 phase 里查看局部变量时特别有用。很多时候 phase 答案就藏在一个栈变量的比较里x/wx直接能看到这个数的十六进制表示。4.2 objdump 反汇编与 strings 先扫后拆少走一半弯路Bomb 的六个 phase 难度递增phase_2 和 phase_3 常涉及循环或分支跳转phase_5 需要从字符数组里取索引phase_6 是链表结构操作。我习惯先用objdump -d bomb生成一份完整反汇编到工程目录下objdump -d bomb bomb.asm strings bomb bomb.stringsbomb.asm是整个可执行文件的反汇编bomb.strings是里面所有可打印字符串。这两份文件不是用来直接抄答案而是给你一个全局地图哪些地址被call了、哪些字符串被比较。常见套路里phase_1调用的比较函数后面会跟着一条内存中的字符串地址地址对应的内容往往正是答案phase_5里会有一个字符数组索引的片段你需要找到0x402780这类基址根据索引值去bomb.strings里复原答案字符串。phase_6 是最繁琐的一个往往需要手动在纸上画出链表节点的顺序。我的做法是在 gdb 里打断点逐个输出节点指针(gdb) break *0x4013d4 (gdb) x/3gx 0x6032d0这里的三个 8 字节值分别是value、next指针和节点顺序索引直接打印出来按顺序排序答案就是你通过调整输入让链表变得递减或递增的排列。这个过程本质上是逆向一个结构体数组手写地址追踪比纯靠人脑记可靠得多。4.3 Attack Lab 的注入与 ROP 边界栈地址不是玄学Attack Lab 是第三版相对于第二版最明显的变革把原来的 buffer lab 从“直接往栈里塞汇编”升级成“攻击代码注入 ROP 链构造”两个任务。首先需要确认目标文件和函数objdump -d ctarget | grep -A 20 getbufctarget是代码注入的目标程序getbuf是你的攻击点函数内部通常会分配一个 32 字节或更小的缓冲区并且编译时禁用栈随机化为了让实验可复现。输入攻击字符串时重点是算出返回地址距离缓冲区开头的偏移。常见做法是在 gdb 里运行gdb ctarget (gdb) break getbuf (gdb) run -q (gdb) info frameinfo frame显示当前栈帧信息包括Saved registers那一行里面有rip保存在栈上的地址用它减去rbp指向的栈帧基址再扣除缓冲区本身的偏移就能算出注入代码的起始位置。如果你偷懒不想算另一个方法是直接p/x $rsp查看栈指针位置在缓冲区内填充 nop 滑梯返回地址指向 nop 序列中间一样能命中你的 shellcode。ROP 阶段不让你注入新代码只能利用已有的 gadget。你需要熟悉几条常见指令pop rdi; ret用于控制第一个参数ret本身是栈指针跳转的推动器。搜索 gadget 时用 objdump 的-M intel参数objdump -d rtarget | grep -B 5 pop %rdi注意提示rtarget的反汇编默认用 ATT 语法地址和寄存器顺序和 Intel 手册相反。用-M intel后阅读体验大幅提升。构造 ROP 链时你需要连续放置多个 8 字节地址每个地址指向一个 gadgetcook 值和参数也要写在栈上。这里最经典的错误是漏掉了ret指令导致链条执行完一个 gadget 后飘到错误地址。5. Cache Lab 与 Malloc Lab性能敏感实验的避坑记录5.1 Cache Lab 的模拟器从 -s -E -b 参数到 LRU 更新策略Cache Lab 分两部分Part A 是实现一个缓存模拟器csim.cPart B 是写一个矩阵转置优化函数。Part A 需要从命令行解析参数模拟地址序列对缓存命中的影响。命令格式是./csim -s 4 -E 2 -b 4 -t traces/foo.trace参数含义-s指定组数索引位的数量实际组数是2^s-E是每组行数-b是块偏移位数-t是 trace 文件路径。模拟器内部需要一个二维结构体数组每个 cache 行包含valid、tag、lru_counter三个字段。每次访问地址时先拆出 tag 和 set index再遍历对应组的每一行void access_cache(unsigned long addr) { long tag addr (s b); int set_idx (addr b) ((1 s) - 1); for (int i 0; i E; i) { if (cache[set_idx][i].valid cache[set_idx][i].tag tag) { hit_count; cache[set_idx][i].lru time_stamp; return; } } miss_count; // 找一个 lru 最小的替换它 int victim find_lru(set_idx); cache[set_idx][victim].valid 1; cache[set_idx][victim].tag tag; cache[set_idx][victim].lru time_stamp; }逻辑说明addr (s b)先清掉组索引与块偏移位留下的就是 tag(addr b) ((1 s) - 1)屏蔽掉高位 tag只保留中间 s 位作为组索引。time_stamp每次访问都自增这样最小 lru 值的行就是最近最少使用的那行替换它即可。Part B 的矩阵转置优化核心是用分块来降低冲突未命中。经典参数是 8×8 分块但在 32×32 矩阵上直接照搬 8×8 可能因为缓存组映射关系反而更差。我建议先用csim-ref也就是官方参考模拟器跑你自己的模拟器对比命中率曲线再逐个分块大小试 4×4、8×8、16×16。优化转置时读入和写出都要及时用完局部变量避免重复访问刚写入的内存。5.2 Malloc Lab从隐式空闲链表到显式空闲链表先跑通再优化Malloc Lab 要求你在mm.c里实现mm_malloc、mm_free、mm_realloc和mm_checkheap评分驱动会读取traces目录下的一批内存请求序列跑完后计算空间利用率和吞吐量。最推荐的起步方案是显式空闲链表用空闲块的头尾部存prev和next指针分配时遍历链表找第一个符合大小且的块。static block_t *find_fit(size_t asize) { block_t *bp freelist_head; while (bp ! NULL) { if (bp-size asize) return bp; bp bp-next; } return NULL; }逻辑说明空闲链表的每个节点都维护自己的块大小和前后指针遍历到第一个满足条件的位置就返回。这属于 first-fit 策略优点是分配速度快缺点是容易产生大量小碎片空间利用率偏低。参数说明asize是已经对齐并加上头部开销后的实际请求大小如果find_fit返回 NULL说明堆内存不够需要调用mem_sbrk扩展堆。mm_free的关键不仅仅是归还块而是立即做边界标记合并把相邻空闲块拼成一个大块void mm_free(void *ptr) { block_t *bp (block_t *)ptr - 1; bp-size | 1; coalesce(bp); }这里ptr - 1是定位块头size的最低位置 1 表示已分配coalesce前后扫描相邻块的标志位如果都是空闲就合并。我在写coalesce时踩过一次坑合并时忘了更新链表指针导致空闲链表出现环mm_checkheap扫描直接死循环。所以实现时的顺序必须是先摘除空闲节点、再修改大小、最后重新插入链表头部。5.3 五个避坑记录现象、原因与解法这套实验做了两三轮我把自己和周围人踩过的坑整理成五条按“现象 → 原因 → 解决”的套路记录了。第一条btest报段错误但dlc检查是干净的。现象是跑一定数量测试用例后进程崩溃原因通常是数组越界或位运算得到的地址非法比如把1 32这种写了进去编译器按0处理但逻辑全错。解决方式是先用-m32和-Wall重新编译让警告浮出来再用 gdb 在崩溃位置bt看调用栈定位到具体函数。第二条cache 模拟器跑 trace 文件时命中率奇低接近零。现象是-s 4 -E 1 -b 4这种参数下全 miss。原因往往是没有正确解析参数-E的值默认成 0或者(1 s) - 1的括号写错导致集合索引被 tag 高位污染。解决方法是打印每个地址的拆分结果手工验证第一个 trace 地址的 tag、set、block offset 是否与预期一致。第三条attack lab 里自己构造的返回地址在本地实验正常放到另一台机器却段错误。原因是实验文档里那个栈地址依赖编译器和运行时布局。解决方式是不要硬编码地址而是在getbuf内用 gdb 打印$rsp后动态计算并把注入字符串中的地址统一替换成这个动态值。第四条malloc lab 本地跑mdriver -t traces/amptjp.rep一切正常但 valgrind 报告 invalid read。现象是堆上有几个字节被越界读原因是分配器的对齐计算少了 8 字节的头部导致返回指针向低地址偏移。解决方式是把align4函数改成align8确保返回值按 8 字节对齐并在mm_checkheap里加边界检查。第五条修改代码后重新评分分数没变甚至更低。原因是make clean没有执行mm.o还是旧版本评分驱动链接的是旧二进制。解决方式是在每个 lab 目录里固定执行make clean make再跑评分脚本把它写成一条命令不要手动分开操作。注意Cache Lab 里的csim-ref是评判标准你的模拟器输出必须和它完全一致包括miss、hit、eviction的顺序和统计。先写一个不带任何优化的最小版本跑通 5 个 trace 后再考虑效率优化。6. 进阶一条命令批量评分与后续实验的推进顺序6.1 用 shell 循环把整套实验串起来把所有 lab 放在同一个根目录下我总是建立一个run_all.sh脚本内容是基于 make 的简单循环#!/bin/bash for lab in data bomb attack cache malloc; do echo $lab cd $lab || exit 1 make clean /dev/null make /dev/null 21 || echo build failed: $lab if [ -x ./driver.pl ]; then ./driver.pl 21 | tail -5 elif [ -x ./csim ]; then ./csim -s 4 -E 2 -b 4 -t traces/yi.trace fi cd .. done逻辑说明每次先make clean再重新编译保证评分用的二进制是刚生成的根据 lab 类型选择不同的验证入口data 和 bomb 用driver.plcache 用自定义的 trace 跑分malloc 用mdriver攻击实验则运行ctarget和rtarget的指定参数。参数说明-s 4 -E 2 -b 4只是验证模拟器能否解析参数真实的 Part B 评分脚本会传入更复杂的-s、-E组合不要把这个参数当成唯一标准。这个脚本的最大价值是避免“改了代码忘了重新构建”。我在第一次做 malloc lab 时连续两次因为没清旧.o文件而误判自己的分配器性能后来强制所有 lab 走同一套 clean-build-run 流程这个毛病就再没犯过。6.2 Shell Lab 之后再动手 Proxy Lab如果你把前面几个 lab 都跑通了接下来我推荐按顺序做 Shell Lab再做 Proxy Lab。Shell Lab 要求你实现一个支持简单命令解析、重定向、管道和信号处理的 shell它把进程管理、文件描述符、信号机制全部串在一起。这一部分反映的是教材第八章“异常控制流”和第十章“系统级 I/O”的综合能力很多人在此之前对fork的理解停留在概念层面写完 shell 才能真正体会到waitpid和execve之间的交互顺序。Proxy Lab 是最后的硬仗实现一个支持并发、正确解析 HTTP 请求、可能还要缓存小文件的代理服务器。它综合了多线程、锁、缓存、socket 编程和 HTTP 协议状态码处理。这部分做完你会发现前面排过的 cache 模拟器的 LRU 思想在这里原样复用但这次干的是真网络流量调试难度更高。常见排查手段是telnet localhost 8080发一个原始 HTTP 请求看代理转发是否带了正确的Host头以及响应长度是否匹配。6.3 一个检查习惯值得你长期保留从那以后我每次拿到新的重构任务或学习项目都会强制走一遍“先建立基线、再修改、再对比验证”的流程。具体到这套实验上就是先把每个 lab 的 makefile 默认代码跑出原始分数把它记录在案然后再开始写自己的实现每次改完代码只允许跑一次评分脚本分数必须不低于基线否则立即回滚查原因。这个习惯帮我筛掉了一大批“看似进步实则因为旧二进制被覆盖而误判”的假象。实验是死的但系统知识是活的希望你也能用这套资源把教材里的抽象段落变成亲自动手验证过的经验希望帮到你。本文还有配套的精品资源点击获取