核心加密框架大整修：Eric Biggers 在 Linux Security Summit 揭露 lib/crypto 現代化進度
LWN.net · 2026-07-08
背景
LWN.net 在 2026-07-08 刊出報導，整理 Google 工程師 Eric Biggers 在近期 Linux Security Summit North America 上針對核心加密框架（Kernel Crypto API）長年結構問題的分享。傳統 crypto_ahash／crypto_shash 這類非同步導向的 API，原本是為硬體加速卡設計，但被大量核心子系統拿來做單純的軟體雜湊或 MAC 運算，因而背上不必要的間接呼叫、記憶體配置與 crypto_tfm 參照計數開銷。TCP Authentication Option（TCP-AO）的實作正是一個典型案例：核心為了繞開 crypto_ahash 在原子上下文（atomic context）下無法配置記憶體的限制，額外做了一整套 tcp_sigpool 機制來預先配置和快取 transform，徒增程式碼複雜度。
Biggers 過去兩年主導的 lib/crypto 專案，目標就是把這類「只需要算出一個雜湊值或 MAC」的呼叫端，直接改用同步、無狀態的函式庫 API，讓編譯器能夠內嵌（inline）並做常數時間（constant-time）強化，同時徹底繞開 crypto API 的動態演算法註冊與 transform 物件生命週期管理。
核心改動
今年稍早由 Biggers 送出、涵蓋 36 個 patch 的 AES library improvements 系列，把散落在 arch/*/crypto/ 下針對 ARM、ARM64、PowerPC、RISC-V、s390、SPARC 與 x86 的最佳化 AES 組合語言實作，全數搬進 lib/crypto/*，讓 lib/crypto 的通用 AES API 也能吃到硬體 AES 指令加速——這是舊版函式庫做不到的，因為舊版通用實作比 aes-generic、aes-arm、aes-arm64 這些既有實作還慢 2 到 4 倍。新的資料結構 struct aes_key 與 struct aes_enckey 取代原本的 struct crypto_aes_ctx，並支援「只準備正向加密方向」的金鑰展開，記憶體用量可省下約一半，對常見的串流類 AES 運作模式（如 CTR、CMAC）特別有利。
另一組同期送出的重構，是把 TCP-AO 從 crypto_ahash 遷移到 lib/crypto，直接砍掉整個 tcp_sigpool 機制，程式碼減少約 275 行。演算法支援範圍也收斂到 RFC 明訂的三種：
- AES-128-CMAC
- HMAC-SHA1
- HMAC-SHA256
官方微基準測試以 128 位元組封包量測 tcp_ao_hash_skb() 的每次呼叫成本，結果相當顯著：
| 演算法 | 改用 crypto_ahash（cycles） | 改用 lib/crypto（cycles） | 改善幅度 |
|---|---|---|---|
| HMAC-SHA1 | 3319 | 1256 | 約 62% |
| HMAC-SHA256 | 3311 | 1344 | 約 59% |
| AES-128-CMAC | 2720 | 1107 | 約 59% |
影響範圍
這波重構的意義不只是效能數字，而是把「該用 crypto API 還是 lib/crypto」的判斷標準明確化：只要呼叫端不需要動態演算法協商、也不在乎硬體卸載，就該走同步的函式庫介面。fscrypt、WireGuard 等既有子系統過去已經是這個方向的早期採用者，而 TCP-AO 與 AES library 的整併則把這條路徑鋪到了通用 AES 這個最基礎的元件上。Biggers 也提到後續會有清理性質的 patch，移除 crypto transform 的複製（cloning）支援，並拿掉 crypto_tfm 的參照計數，屆時效益將回饋給所有仍然使用傳統 crypto API 的呼叫端，而不只是已經遷移的部分。
原始來源：LWN.net：Progress in modernizing kernel cryptography、LWN.net：AES library improvements、LWN.net：Reimplement TCP-AO using crypto library
Go 1.26.5 與 1.25.12 修補兩項安全漏洞：os.Root 符號連結逃逸與 ECH 隱私外洩
oss-security mailing list · 2026-07-08
Go 官方於 2026-07-07 發布 Go 1.26.5 與 Go 1.25.12，修補兩個獨立的資安問題：CVE-2026-39822（os 套件的 os.Root 目錄逃逸）與 CVE-2026-42505（crypto/tls 套件的 Encrypted Client Hello 隱私外洩）。消息由 Go security team 透過 oss-security 郵件列表於隔天 2026-07-08 公告，並附上官方 release notes 連結。
漏洞機制
CVE-2026-39822 出在 Unix 系統上 os.Root 的路徑處理邏輯。問題根源是 openat(fd, path, O_NOFOLLOW) 在路徑以斜線結尾時，核心行為並不會真的阻擋符號連結：當呼叫端執行 root.Open("symlink/")，即使 symlink 指向 root 目錄之外的位置，O_NOFOLLOW 也無法發揮作用，導致原本應該被侷限在沙盒根目錄內的檔案存取，能夠跳出邊界讀寫任意路徑。這個問題由 GitHub 使用者 M0nd0R 回報，並在 Go issue tracker 的 golang/go#79005 中追蹤。
CVE-2026-42505 則發生在 crypto/tls 的 Encrypted Client Hello（ECH）實作。ECH 原本的設計目的是把 TLS 交握中會暴露伺服器身分的 ClientHello 加密起來，避免被動側錄者得知使用者實際連線的網站。但目前實作把預先共享金鑰（pre-shared key）的識別碼放在未加密的外層 ClientHello 中傳送，等於讓能夠側錄封包的被動觀察者，即使看不到內層加密內容，也能靠 PSK identity 反推出對應的伺服器身分，讓 ECH 原本要防禦的去匿名化攻擊形同虛設。此問題由 Coia Prant 回報，追蹤於 golang/go#79282。
受影響版本
兩個問題都影響所有先前版本的 Go 1.26.x 與 Go 1.25.x 分支，官方在 issue tracker 中將修復掛在下一個開發里程碑 Go 1.27，再透過 CherryPickApproved標籤回焒（cherry-pick）到目前仍受支援的兩個穩定分支。
CVE-2026-39822— 影響套件：os（僅 Unix 系統）CVE-2026-42505— 影響套件：crypto/tls（啟用 ECH 的連線）
| CVE | 受影響套件 | 修補版本 |
|---|---|---|
| CVE-2026-39822 | os | Go 1.26.5 / Go 1.25.12 |
| CVE-2026-42505 | crypto/tls | Go 1.26.5 / Go 1.25.12 |
修補與緩解
os.Root 的修法是在把路徑參數交給底層 openat 之前先做淨化處理，去除會觸發核心「結尾斜線繞過符號連結檢查」行為的路徑寫法，讓 O_NOFOLLOW 恢復原本應有的邊界保護效果。ECH 的修法方向則是把 PSK identity 從外層明文 ClientHello 移除，只保留在加密的內層 ClientHello 中，如此一來即使外部觀察者能看到未加密的外層封包，也拿不到可用來關聯伺服器身分的識別碼。兩項修補都已經包含在 Go 1.26.5 與 Go 1.25.12 的正式釋出中，使用 os.Root 沙盒機制或啟用 ECH 的服務／客戶端應盡快升級。
原始來源：oss-security：Go 1.26.5 and Go 1.25.12 fix two vulnerabilities、go.dev release notes、golang/go#79005、golang/go#79282