2026-06-25 — systemd v261 釋出、libarena 為 BPF arena 提供通用函式庫、ffs 直讀磁碟區塊挑戰 VFS

systemd v261 正式釋出：雲端元資料服務、無 TPM 開機金鑰與跨核心熱更新齊登場

GitHub · 2026-06-19

systemd v261 於 2026 年 6 月 19 日正式發布，帶來三項主要新功能：雲端 Instance Metadata Service（IMDS）子系統、無 TPM 硬體環境下的開機金鑰機制，以及與 Linux 核心 Kexec Handover（KHO）整合的即時更新協調器（Live Update Orchestration）。這個版本同時包含多項破壞性變更，升級前需留意組態格式的調整。

雲端元資料服務：IMDS 子系統

全新的 systemd-imdsd 守護程序透過 Varlink API 統一存取雲端平台的 Instance Metadata。目前支援 EC2、Azure、GCP、Hetzner、Oracle Cloud 等主流雲端供應商，讓在多雲環境部署的服務能以一致介面取得主機憑證與組態資訊。搭配新增的 systemd-imds 命令列工具，可直接匯入雲端憑證至系統。這組工具的定位類似 cloud-init 的低層基礎，但以 systemd 原生方式整合進開機流程。

無 TPM 環境的 Boot Secret 機制

過去需要全磁碟加密或遠端證明的場景，幾乎都依賴 TPM 晶片存放加密金鑰。v261 引入的 Boot Secret 功能讓不具備實體 TPM 的系統也能產生持久化的 EFI 基礎開機金鑰，由 systemd-stub 生成後存放於 initrd 的 /.extra/boot-secret 路徑。此外，新增的 systemd-tpm2-swtpm.service 還提供軟體 TPM 回退方案（software TPM fallback），進一步擴大安全開機的適用範圍。

TPM 量測方面也有強化：新增的 systemd-pcrosseparator.service 服務會將韌體與 OS 的分界點量測寫入 PCR，並提供 ConditionSecurity=measured-os 讓 unit 可驗證系統是否處於量測開機狀態。Stub 現在額外量測 devicetree、initrd、ucode 等事件至 EFI_CC_MEASUREMENT_PROTOCOL，這一變更會改變遠端證明（remote attestation）時預期的 PCR 數值，升級時需重新建立信任基線（trust baseline）。

即時更新協調（LUO）與 Kexec Handover

Linux 核心從 6.14 起引入 Kexec Handover（KHO）機制，允許在 kexec 核心切換時保留部分核心狀態。systemd v261 的 PID 1 現在能在核心支援時，透過 KHO 保存 FD Store 跨越 kexec 操作，使服務的檔案描述符在核心熱升級後仍然存活，讓有狀態服務的零停機核心更新成為可能。這一功能標記為 Live Update Orchestration（LUO）支援，目前需核心啟用對應選項才會生效。

服務管理器與網路層改動

服務管理器新增 MinimumUptimeSec=（預設 15 秒）防止服務快速重啟迴圈，以及 FileDescriptorStorePreserve=on-success 讓 FD Store 僅於成功退出時保留。ConditionFraction= 以機器 ID 雜湊實現分批灰度部署，可直接在 unit 層級控制 fleet 推出比例。RestrictFileSystemAccess= 改用 BPF LSM 進行 dm-verity 驗證，強化了容器與沙箱環境的存取控制。

網路方面，networkctl dhcp-lease INTERFACE 新指令可直接檢視 DHCP 租約細節。DHCPRelay 設定從 DHCPServer 段落遷移至 [Network] 段落，舊的 BindToInterface、RelayTarget 等選項已廢棄。systemd-resolved 支援 /etc/systemd/resolve/static.d/ 下的 JSON drop-in 靜態 DNS 記錄，並新增多項快取大小調整選項（DNSCacheSize、MulticastDNSCacheSize、LLMNRCacheSize）。

破壞性變更摘要

• io.systemd.Unit Varlink 介面的部分欄位轉為 enum 型別，輸出格式由連字號（-）改為底線（_）
• systemd-nspawn 的 --user= 選項更名為 --uid=，--user 重新用途為獨立旗標
• 移除 udev 舊版資料庫格式（version 0），不再支援從 v247 以前直接熱升級
• musl 最低版本提升至 1.2.6
• 多個依賴庫（libgnutls、libcurl、libcryptsetup 等）改用 dlopen() 動態載入，libgpg-error 依賴已完全移除

vmspawn 虛擬機器管理在這個版本也大幅擴充，新增 AMD SEV-SNP 機密運算支援（--coco= 旗標）、PCIe root port 預先分配（支援熱插拔）、NVRAM 持久化選項以及多種儲存後端選擇（virtio-blk、nvme 等），讓 systemd 在 VM 生命週期管理的角色更接近輕量 hypervisor 工具。

原始來源：systemd v261 Release Notes — GitHub · LWN.net 報導

BPF 程式開發新工具箱：libarena 為核心態記憶體競技場提供通用函式庫

libbpf / GitHub · 2026-05-19

Linux 核心 BPF 子系統在 6.9 版引入 BPF_MAP_TYPE_ARENA 後，開發者得以在 BPF 程式與使用者空間之間共享大塊連續記憶體（arena），但如何在這塊記憶體上做動態配置、偵測記憶體錯誤，長期缺乏統一的工具。Meta Platforms 工程師近期以獨立函式庫 libarena 的形式，將原本散落於核心 selftests/bpf 的 arena 輔助標頭統整發布，初版於 2026 年 5 月 19 日上線，目前仍處於早期階段。

背景：BPF Arena 是什麼

BPF_MAP_TYPE_ARENA 是一種特殊的 BPF map，在使用者空間與 BPF 程式的位址空間中分別以 mmap 映射同一塊實體記憶體。程式可以直接用 C 指標操作這塊記憶體，不需要透過 map helper 呼叫，大幅降低核心驗證器（verifier）的複雜度負擔，也使複雜資料結構（如鏈結串列、樹狀結構）可以在 BPF 程式中直接實作。Arena 位址空間依架構不同，ARM64 起始於 1ull << 32，其他架構起始於 1ull << 44，由 bpf_addr_space_cast 機制在核心驗證器層次區分一般指標與 arena 指標。

核心元件：Buddy 配置器

libarena 目前最核心的元件是針對 BPF arena 特性設計的 Buddy 配置器（buddy.h / buddy.bpf.c），管理單位為 1 MiB 的 buddy_chunk，最小配置粒度 16 bytes，支援最大 16 個 order（即最大單次配置約 32 KiB）。每個 chunk 以 4-bit 欄位記錄每塊的 order，搭配 bitmap 追蹤已配置狀態，free-list 採 O(1) 配置策略。

主要 API 為：

buddy_init(allocator);          /* 初始化配置器 */
buddy_alloc(allocator, size);   /* 配置，回傳 arena 位址限定指標 */
buddy_free(allocator, ptr);     /* 釋放 */
buddy_destroy(allocator);       /* 清理 */

配置器本身以 BPF C 撰寫，直接在 BPF 程式內執行，不需要離開核心態，適合需要動態記憶體管理的高效能 BPF 應用，例如封包追蹤、eBPF LSM 策略引擎。

AddressSanitizer 整合

libarena 提供 ASAN（AddressSanitizer）運行時（asan.h / asan.bpf.c）。其設計採用影子記憶體（shadow memory）架構：每 8 bytes 的 arena 記憶體對應 1 byte 的影子記憶體，以 3-bit 移位計算影子位址，透過 asan_poison() / asan_unpoison() 管理記憶體安全狀態。當定義 BPF_ARENA_ASAN 時啟用完整檢測；否則使用存根實作，不影響正常編譯。這讓開發者可以在測試環境中偵測 arena 記憶體的越界存取，而不需要額外的核心模組。

元件概覽與使用方式

libarena 以鏡像方式（mirror-only）發布於 GitHub，主要開發仍在核心 BPF 郵件清單（BPF kernel mailing list）上進行，GitHub 端的 scripts/sync-kernel.sh 定期從核心樹同步。函式庫採雙授權（LGPL-2.1 OR BSD-2-Clause），並刻意不綑綁 libbpf 標頭以避免版本相容問題。使用前需自行提供 vmlinux.h，且編譯環境必須支援 __BPF_FEATURE_ADDR_SPACE_CAST（需要支援 arena 特性的 LLVM 版本與 Linux 核心 6.9+）。對於計畫在 BPF 程式中實作複雜資料結構或動態記憶體池的開發者，libarena 提供了由核心維護者背書的標準起始點，免去從 selftests 手動複製標頭的繁瑣。

原始來源：libbpf/libarena — GitHub · LWN.net 報導

繞過核心直讀磁碟區塊：ffs 用 1500 行 C 挑戰 VFS 快取的邊界

GitHub (dmtrKovalenko/ffs) · 2026-06-15 初版

一個名為 ffs（F* File System） 的命令列搜尋工具在 2026 年 6 月 15 日公開，以約 1,500 行 C 程式碼實作了完全繞過 Linux/macOS 核心 VFS 層的檔案搜尋：它直接呼叫 pread() 讀取原始區塊裝置，自行解析 Ext4、Btrfs、APFS 的二進位格式來走訪目錄樹與讀取檔案內容。作者 Dmytro Kovalenko 直言這個工具「幾乎沒有實用性，但相當酷」，並在 README 中建議真正需要效能的使用者改用他的另一個專案 fff。

架構：直接 I/O 與自行實作的檔案系統解析器

傳統的 grep、ripgrep 等工具透過 VFS 的 read() 系統呼叫存取檔案，核心負責快取、頁面管理與鎖定。ffs 的做法是完全繞開這條路徑，直接對 /dev/sdX（Linux）或 /dev/rdisk*（macOS）等原始裝置節點呼叫 pread()，取得磁碟區塊後以各檔案系統專屬的二進位格式解析 inode、目錄項目與資料區塊。搜尋過程中以 OpenMP 將工作分散至多個 CPU 核心並行處理，並自動偵測跳過二進位檔案。

這個方法有幾個直接後果：存取未掛載的磁碟區（或 .dmg、.iso 映像檔）完全不需要掛載即可搜尋；對掛載中的磁碟，最近尚未 sync 到磁碟的寫入可能被遺漏，因為 ffs 不知道核心頁面快取的狀態；存取原始裝置節點需要 root 權限（sudo），但映像檔不需要。

# 編譯（需要 libzstd、OpenMP、pkg-config）
make ffs

# 搜尋未掛載的磁碟映像（無需 sudo）
ffs "<QUERY>" /path/to/volume.dmg apfs

# 搜尋已掛載的磁碟（需要 sudo）
sudo ffs "<QUERY>" /dev/sda1 ext4

三種檔案系統的實作差異

Ext4 是三者中最易實作的：Ext4 採就地寫入（write-in-place）配合 journaling，區塊結構相對穩定，是 ffs 最完整支援的格式。Btrfs 因寫入時複製（Copy-on-Write）的特性更複雜——每次檔案更新都會改變 superblock，若核心同時修改樹狀結構，ffs 的讀取結果可能失效；作者建議在 Btrfs 上搜尋前先執行 fsfreeze 凍結寫入。APFS 最棘手：Apple 從未公開完整規格，ffs 依靠逆向工程的格式知識解析 APFS B-Tree 結構，在 macOS 主磁碟上使用還需關閉系統完整性保護（SIP）。

效能：大資料集下的差距

作者以 Btrfs 磁碟機對 ffs 與 ripgrep 進行比較測試，結果顯示在小型已快取目錄上 ripgrep 仍然較快，但隨著檔案數量增加，VFS 快取命中率下降，ffs 的優勢開始浮現：

在 3.25M 檔案的情境下，ffs 的速度約為 ripgrep 的兩倍。作者認為這個差距來自 VFS 快取在超大型目錄樹下的 overhead——當核心必須管理大量 inode 快取並頻繁驅逐時，直接讀取磁碟的固定成本反而更低。

工程意義：VFS 的代價與直接 I/O 的邊界

ffs 最大的工程趣味在於它把一個通常隱形的問題具體化：VFS 抽象層的快取機制在超大規模搜尋時會成為瓶頸，而不是加速器。這與 io_uring 或 SPDK 之所以存在的動機相似——在特定工作負載下，繞過核心的通用路徑往往能取得更好的延遲與吞吐量。另一方面，ffs 也清楚展示了直接 I/O 的代價：失去一致性保障、需要自行解析各檔案系統格式、需要額外權限。截至 2026 年 6 月 23 日，專案仍在活躍開發中，最近提交集中於 APFS 解析修正與文件改善。

原始來源：dmtrKovalenko/ffs — GitHub