9.30

#diary #2025/9

嘹亮的琴音

中午在一餐吃饭时，久违地听到了钢琴奏响的声音，似乎因为空间宽阔的原因，显得高亢而嘹亮。弹奏了一首海阔天空以及若干我无法识别出名字的歌曲。

九月的尾巴

这是最后一篇带有 tag #2025/9 的日记。

失败的 Attack

启动 attack lab 时发现在输出 Type string 之前就触发了 Segmentation fault。通过阅读反汇编和 gdb breakpoint/backtrace 等多管齐下，发现触发 segmentation fault 的原因是 printf 中的 movaps %xmm1, 0x10(%rsp) 中没有满足对齐要求。

为了验证我的猜测（实际上直接用 gdb 改 rsp 就能进行一定程度上的验证），通过成功运行过 attack lab 的奶龙机器获取到了一些 gdb 的调试信息，发现 rsp 仍然没有对齐，不过没有崩溃的原因未知，于是尝试通过独立运行 movaps 指令来进行验证（确认猜测），不过更令人困惑的情况是，奶龙机器同样对这份代码产生了 Segmentation Fault。这无疑让我深入了深深地思考（错误地排除了正确原因），开始怀疑是链接 C 库的版本不同的原因（开始偏题），尝试更新 GLIBC，由于 apt 的机制，需要处理复杂的包依赖问题（linux-nvidia6.2-tools-common 和 linux-tools-common），出于保守性，令而配置了 docker 的环境（顺带学了学 docker 的用法），在 docker 的 Ubuntu22.04 中尝试了 WSL 中尝试过的一切，包括更新 GLIBC，仍然没有解决问题（从相同的 Ubuntu 版本和 WSL2 作为 docker 的后端中可见一斑）

section .text
    global _start
_start:
    call test_unaligned
    mov rax, 60
    mov rdi, 0
    syscall
test_unaligned:
    push rbp
    mov rbp, rsp
    and rsp, -16
    sub rsp, 8
    movaps xmm0, [rsp]
    mov rsp, rbp
    pop rbp
    ret

在穷途末路之际，尝试让 DS 直接检索类似遭遇的网页，出现了一些有效的信息但是仍然无法解决问题，最后灵机一动切到英文版搜索结果第一个就跳出来 stack overflow post 问题完全匹配！
发现了同样的问题根源： movaps 的对齐，帖子提到通过 run-time interpositioning 来解决问题并一针见血地指出问题存在的原因是 System V AMD64 ABI 的提出时间晚于 Attack Lab 的最后更新时间。其他相关的帖子

所以奶龙机器是一台混沌的机器。

通过这次奇妙的 debug，或许可以总结出一些教训