在 C 里写 *p，很容易以为代码一执行就按住了地址 p 对应的内存位置。但程序到 DIMM 之间其实还隔着好几层：虚拟地址先转成物理地址，再穿过缓存和片间互联，最后才到内存控制器。控制器内部还要继续做通道、rank、bank 交错，拆成 row 和 column 才能发给颗粒。我们常说的内存安全围栏，大多数都建立在「物理地址」这一层。
skitter-creek-bath-salts 这个项目动的是更底下的那一层。作者 Christopher Domas 修改了 DRAM 控制器里的地址变换逻辑，让同一个物理地址最终落到另一颗存储电容上。上层保护机制还盯着原来的“门牌号”，电容却已经换了对象。仓库名字看着很奇怪，装的是在 AMD Family 16h 上验证过的研究代码。
Family 16h 是官方数据手册里还列出这些地址变换寄存器的最后一代，而且看上去没有被锁住。到 17h 之后，手册就不再公开这些细节了。作者也承认，类似的地址变换在 Intel、ARM、RISC-V 平台上同样存在，这个仓库的价值在于摸清了一条具体入口。
改动本身像拨一个开关，难点在于别让机器当场挂掉。大致做法是：先把其他核停掉，预热 TLB 和缓存，关闭中断，尽量减少后续对 DRAM 的触碰，改完读一次，再马上改回去。作者用 C 写了一个演示：映射一拧，&x 指向的内容就不再是原来那一个位置了。
映射切过去以后，内存看起来就像一团乱麻。这层地址变换可以近似成有限域 GF(2) 上的线性映射，比特之间主要靠异或组合，因此很适合丢给求解器处理。作者的玩法是：在正常视图写入一个哨兵值，切到打乱视图扫内存看它出现在哪个位置，积累一批「原地址—别名」的对应关系。解出来的矩阵就像一本地址对照表。对于受保护区域的物理地址，可以算出一个对应的别名；别名走的是打乱后的路径，那些基于正常门牌号建立的防护围栏自然就够不着它。
按照官方材料，这个别名路径能够触碰到几处普通内核也进不去的 DRAM 区域。PSP（Platform Security Processor） 有自己的 ARM 核，fTPM 就运行在上面，它的私有内存位于可见内存顶部的 carveout 区域。作者从这块区域里挖出了 RSA 模幂函数的反汇编代码。SMM 则更古老：系统管理模式的入口位于 SMBASE + 0x8000，芯片组本来应该让 SMRAM 不可读。核心进入 C6 休眠时，还会把寄存器现场以及唤醒后需要重新加载的微码补丁塞进另一块 DRAM。作者在那块休眠现场里，对上了本机正在运行的 Family 16h 微码。
这些目前都属于研究性演示。仓库提供了内核模块和用户态工具，执行 make 即可编译。程序启动时会先做平台检查，机器不匹配就直接退出。运行需要 root 权限。data/maps/ 目录下有针对 2x4GB 内存条的现成映射表；如果内存条规格对不上，就需要自己采集别名并重新求解。
make
./userspace/platform_check
不建议在主力电脑上尝试。映射一旦写错，机器可能直接死掉。作者计划在 Black Hat 2026 做题为 Spaghettifying DRAM 的分享。目前的验证范围只覆盖特定的老 AMD 平台，其他平台不要直接套用。这个项目也把一件容易混淆的事情拆得很清楚：调试器里看到的物理地址，和 DIMM 上真正被点亮的那一格，中间还隔着内存控制器自己的一套“揉面”逻辑。
项目主要用 C 和 Python 编写，MIT 许可证，作者 Christopher Domas（@xoreaxeaxeax）。
仓库： https://github.com/xoreaxeaxeax/skitter-creek-bath-salts
如果你对这类底层硬件安全研究感兴趣，也欢迎到 云栈社区 一起讨论。
参考资料
[1] skitter-creek-bath-salts: https://github.com/xoreaxeaxeax/skitter-creek-bath-salts | 
发表于 7 天前
|
查看: 2|
回复: 0
