把 DRAM 位址打成一碗麵：這週工程冷知識三則,從記憶體打散術到 SQL 等式圖優化器
news.ycombinator.com / lobste.rs · 2026-08-12 ~ 2026-08-14
把 DRAM 位址打成一碗麵
現代 CPU 的記憶體控制器不會把作業系統看到的實體位址原封不動寫進 DRAM，而是先做一層位址打散（DRAM scrambling）——把位址映射到實際的 row/column/bank，一部分是為了效能與訊號完整性，另一部分則被當成廉價的防護層：只要攻擊者猜不出打散規則，SMRAM、PSP 這類受保護區域就相對安全。研究者 Christopher Domas（xoreaxeaxeax，以 sandsifter、smiiiiiiiiiiiiiiii 等 x86 底層研究聞名）在新專案 skitter-creek-bath-salts 裡指出，這層打散在 AMD Family 16h 上其實是 GF(2) 上的線性變換，可以用 Z3 SMT solver 蒐集「兩個實體位址映射到同一顆 DRAM cell」的別名對，反解出整個變換矩陣。
解出矩陣之後就能算出偽逆矩陣，把 PSP 私有記憶體、SMRAM、C6 省電狀態暫存的核心內容、甚至待載入的 CPU microcode，統統轉換成一般記憶體視圖下可讀寫的別名位址。專案文件用一句話總結整套手法：「Physical addresses are really more of a suggestion.」實際操作只需要翻轉 DCT 暫存器的一個設定位，例如 xor dword [0xf80c2094], 0x00400000 這行組合語言，就能讓位址臨時落到完全不同的 DRAM 位置，繞過所有建立在「記憶體視圖是一致的」這個假設之上的安全機制。
整套流程分成核心模組 spaghettify.ko 負責低階存取，以及使用者空間工具鏈：
dram_dump/dram_poke— 讀寫指定 DRAM 位置dram_carveouts/platform_check— 列舉受保護區域與平台相容性gather_aliases.py/unspaghettify.py— 蒐集別名對並反解打散矩陣
攻擊時序也很講究：先關掉其他 AP core、預熱 TLB 與快取、關中斷，才短暫切換 DCT 設定去存取受保護記憶體，再立刻還原正常映射。這份研究預定在 Black Hat 2026 發表，把攻擊面從分頁與快取一路下推到記憶體控制器本身，也解釋了為什麼 HN 與 Lobsters 這幾天都在討論它。
拿等式飽和演算法蓋 SQL 優化器
傳統 SQL 優化器最頭痛的問題是「規則套用順序」：先做常數折疊還是先做謂詞下推，結果可能完全不同，工程師只能靠經驗排優先順序。Rust 社群的 e-graph 函式庫 egg 用等式飽和（equality saturation）繞開這個順序問題——它不急著挑一種改寫結果，而是把運算式的所有等價形式同時塞進一張圖裡（e-node 是單個運算，e-class 是彼此等價的 e-node 集合），等飽和之後再用成本函數挑出最優解。
RisingLight 這個教學型資料庫專案用不到一千行 Rust、靠 define_language! 巨集定義 SQL 表達式的語言，重寫了整套查詢優化器，涵蓋謂詞下推、欄位裁剪、Join 重排與成本估算四類經典優化。Join 重排利用內連接的交換律與結合律枚舉不同順序，再透過實作 CostFunction trait 的成本函數挑出開銷最小的執行計畫；文章提到這套優化器能直接跑真實的 TPC-H 查詢，並在約 100 毫秒內給出結果。對比手寫規則引擎要一條條處理套用順序，egg 把「探索所有等價形式」這件事變成了資料結構層級的問題。
沒有 PgBouncer，Postgres 還能撐多久
Brandur Leach 在 《Does anyone run Postgres without PgBouncer?》裡問了一個看似基本卻很少人細想的問題。Postgres 每個連線都對應一個作業系統行程，開銷遠比執行緒模型高，這是十年前就有人寫過的老問題，至今沒有解掉；PgBouncer 之所以幾乎變成標配，正是因為它在應用端與資料庫之間插入一層輕量連線池，把大量短暫的客戶端連線多路復用成少量長駐的真實 Postgres 連線。
文章列出一張表，檢查市面上主要的受管理 Postgres 服務是否內建連線池：
- Aiven、Alibaba RDS、AWS RDS/Aurora、Azure Database
- Crunchy Bridge、DigitalOcean、EDB、Fly.io
- Google Cloud SQL、Heroku、Neon、Railway、Render、Supabase
結果幾乎是百分之百都內建了某種形式的連線池。Brandur 的推論是：如果幾乎每一家做 Postgres 代管生意的廠商都覺得不能讓使用者赤裸裸直連資料庫，那連線管理就不只是「使用者不會用」的問題，而是產品本身要解決的問題。他也順帶提到 Postgres 社群內部關於「行程模型該不該換成執行緒模型」的老爭論，指出目前很少有貢獻者的資歷夠深，足以推動這種底層改動往前走。
原始來源：skitter-creek-bath-salts (GitHub)、Write a SQL Optimizer using Egg (Rust Magazine)、Does anyone run Postgres without PgBouncer? (brandur.org)