Linux 6.16 overlayfs：非特權容器可直接使用 metadata/data-only 層
KernelNewbies / Linux 核心變更日誌 · 2026-06-12
Linux 6.16 核心在 overlayfs 子系統中落地了一組由 Amir Goldstein 主導的改動，允許 metadata-only 與 data-only 層在 user namespace 下直接掛載，不再需要超級使用者權限。此項更新於 2026 年 6 月的 Linux Storage/FS/MM/BPF Summit 上公開說明，主要受惠情境是在非特權容器中運行 composefs。
背景
overlayfs 是 Linux 的聯合掛載（union mount）實作，廣泛被 Docker、Podman 等容器執行環境用來堆疊映像層。composefs 是建立在 overlayfs 之上的映像格式，透過分離「元資料層」與「資料層」的方式提供可驗證的映像內容；然而在此次改動之前，這類分層掛載仍要求呼叫端持有 CAP_SYS_ADMIN，在無 root 的容器環境中使用受限。
User namespace（user_ns）機制讓非特權行程得以在隔離的命名空間內模擬擁有完整能力，但 overlayfs 的層驗證邏輯並未對此情境放行 metadata/data-only 層，造成 rootless 容器工具在使用 composefs 時的明顯缺口。
核心改動
此次共有三組提交進入 Linux 6.16 主線，整體保持向後相容：
- 層權限驗證邏輯調整：修改 overlayfs 在 user namespace 內對層掛載選項的能力檢查，移除原本強制要求
CAP_SYS_ADMIN的限制路徑。 - data-only 層的 user namespace 支援：讓純資料層（不含目錄元資料）在非特權掛載流程中能正確初始化與掛載。
- metadata-only 層的 user namespace 支援：對應地允許僅含元資料的層在同等條件下掛載，完成 composefs 所需的「元資料與資料分離」模型。
現有以特權方式掛載的行為不受任何影響，僅在 user namespace 情境下新開放了先前不允許的掛載路徑。
影響範圍
最直接的受益者是以使用者命名空間執行的容器工具。Podman rootless 與 Buildah 可在不要求宿主機提升權限的情況下，直接利用 composefs 的映像驗證特性，降低供應鏈攻擊的風險面。
對於需要在多租戶環境（如 Kubernetes 節點）部署容器的場景，此改動意味著：
- 映像層可在沙箱邊界內完成 fsverity 驗證，不需要 suid 輔助程式
- composefs 的元資料/資料分離模型在無特權情境下得以完整運作
- 降低了需要
newuidmap/newgidmap以外的額外特權設定需求
此功能隨 Linux 6.16 合併，預計在下游發行版（如 Fedora、Ubuntu）的對應核心版本中生效。composefs 上游社群亦計畫在工具鏈層面跟進，讓 rootless 容器的映像驗證流程更為完整。
Apple 將 TrueType Hinting 直譯器從 C 改寫為 Swift：效能提升 13%、記憶體安全零事故
Swift.org Blog · 2026-06-12
Apple 工程師在 Swift 官方部落格披露了一項在 macOS 與 iOS Fall 2025 版本中完成的系統級移植：將沿用多年的 TrueType hinting 直譯器從 C 重寫為 Swift，最終達到平均 13% 的效能提升，並在上線後實現零記憶體安全 bug 回報。這是 Swift 在蘋果核心系統元件中大規模應用的首批公開案例之一。
背景
TrueType hinting 直譯器是字型渲染管線的關鍵元件，負責執行嵌入字型中的特殊用途位元組碼，讓字形在低解析度螢幕上維持視覺品質。該直譯器長年以 C 實作，歷史積累深厚，但 C 語言在指標操作與記憶體管理上的彈性也讓它難以靜態保證安全性。此移植的正確性標準格外嚴格：新實作必須輸出與原 C 版本像素完全相同的字形點陣圖，任何視覺差異都不被接受。
測試規模反映了這項要求的嚴謹程度：驗證涵蓋 macOS 上所有隨附字型，加上非系統字型，共 25,572 個嵌入字型、27,000,000 個字形，每個字形執行 4 種不同變換，並以點陣圖比對方式驗證輸出與參考直譯器完全一致。
核心改動
移植過程中，工程師採用了數項針對效能的 Swift 特有技術。首先是 Noncopyable 型別（~Copyable）：以值語意型別取代可能觸發 ARC（自動參考計數）的參考型別，大量減少執行時的 retain/release 開銷。
原型實作中，跨語言邊界複製字形資料的成本高達執行時間的約 20%。工程師引入投影型別（Projection Types），以帶有生命週期標記的 Ref 直接存取底層 C 資料結構，避免不必要的複製。堆疊操作也從傳回 [Element] 的配置路徑，改為 continuation-passing 風格消除堆積配置：
// 原本的堆疊彈出（heap allocation）
mutating func pop(count n: Int) -> [Element]
// 改用 continuation-passing 消除配置
mutating func pop<R>(count n: Int,
_ op: (borrowing Span<Element>) throws -> R) rethrows -> R
熱路徑上凡能以顯式迴圈加 continue 取代的 filter/map 呼叫，皆改以惰性求值處理。動態派發亦透過謹慎的抽象設計完全排除，讓最佳化器得以內聯並特化泛型上下文，不引入額外間接層。
影響範圍
效能驗證以 CPU megacycles per glyph 為指標，覆蓋所有 macOS 隨附字型及部分非系統字型，Swift 版本平均領先原 C 實作 13%。程式碼覆蓋率達 99.7%，使用 4,200 份模糊器最小化的 PDF 文件作為語料庫。
記憶體安全方面，上線後至今零回報 bug，不安全程式碼被限縮至語言互通邊界的最小範圍。自訂的 FixedPoint、StackElement 等型別在不增加執行時成本的條件下提升了程式碼可讀性，體現 Swift「零成本抽象」的設計目標。此移植案例顯示，在需要 C 互通且對效能敏感的系統元件上，Swift 已具備實戰可行性，可作為後續系統層移植的參照模型。
原始來源：Swift.org — Migrating the TrueType Hinting Interpreter to Swift
WASI 0.3 正式發佈：WebAssembly Component Model 獲得原生非同步支援
Bytecode Alliance · 2026-06-11
Bytecode Alliance 於 2026 年 6 月 11 日正式宣布 WASI 0.3 規格完成，為 WebAssembly Component Model 引入首個一等公民的非同步原語。此版本在 Canonical ABI 層面新增 stream<T>、future<T> 以及 async 函式導出，徹底取代 WASI 0.2 中繁瑣的三步式事件訂閱模式。
背景
WASI 0.2 的非同步模型採用就緒通知（readiness-based）方式：呼叫端必須先以 start-foo 發起操作，再用 subscribe 訂閱 resource pollable，最後呼叫 finish-foo 取得結果。這種「start/finish/subscribe 三步舞」不僅冗長，也難以與各語言的原生非同步模型（Rust async/await、Python asyncio 等）直接對應，大幅增加了語言繫結的實作負擔。
WASI 0.3 的設計靈感來自 Linux io_uring 和 Windows IOCP 所代表的完成通知（completion-based）模型，將事件迴圈的控制權從元件本身移交給宿主（host）統一管理，元件只需宣告意圖，由執行時排程實際的 I/O 完成事件。
核心改動
Canonical ABI 新增三個核心構造。stream<T> 類似資源型別，持有可讀或可寫的串流句柄，可跨元件邊界轉移所有權；future<T> 表示最終將產生單一值的非同步操作，所有權轉移後不可借用；async 函式讓元件可直接導出或導入非同步函式，不再需要分拆為 start/finish 兩個入口點。
WASI 0.2 與 0.3 的介面對應關係如下：
| WASI 0.2 | WASI 0.3 |
|---|---|
resource pollable | future<T> |
resource input-stream | stream<u8> |
poll(list<pollable>) | 對 future 執行 await（由執行時處理） |
串流的錯誤處理也獲得修正：WASI 0.2 中呼叫端若未持續讀取則無法得知操作結果；WASI 0.3 的串流回傳 tuple<stream<u8>, future<result<_, error-code>>>，資料流與完成狀態彼此獨立，可分別等待。
影響範圍
語言繫結方面，各語言的 guest 工具鏈正陸續加入原生非同步支援：
- 無堆疊協程（stackless coroutines）：Rust、Python、JavaScript、C#、C
- 有堆疊協程（stackful coroutines）：Go（goroutine 將被轉換為 async 呼叫）
執行時方面，Wasmtime 46 將預設啟用 WASI 0.3.0 非同步支援；JavaScript 工具鏈 Jco 的完整 WASI 0.3 支援版本亦即將發布。最具代表性的效益是服務元件串接（service chaining）：兩個 WebAssembly 元件可直接以函式呼叫組合，省去跨行程或跨網路的通訊開銷，將呼叫延遲從毫秒級縮減至奈秒級，足足差了六個數量級。
原始來源：Bytecode Alliance — WASI 0.3 launched with native async support for WebAssembly Components