Systemd v261 釋出：雲端 IMDS 子系統、Boot Secret 與 Live Update Orchestration 全面登場
systemd/systemd GitHub Releases · 2026-06-19
2026 年 6 月 19 日，systemd 專案依循三個月發佈周期釋出 v261，簽名提交雜湊為 de9dbc37ad4aa637e200ac02a0545095997055df。本版本新增雲端 Instance Metadata Service（IMDS）子系統、無 TPM 環境的 Boot Secret 機制，以及透過 kexec handover（KHO）實現的 Live Update Orchestration（LUO）支援，並帶來大量 Varlink API 擴充與多項破壞性變更。
雲端元資料服務（IMDS）子系統
新增的 systemd-imdsd 常駐程式提供對雲端供應商實例元資料的本地 Varlink IPC 存取，硬體資料庫新增對下列平台的識別：Amazon EC2、Microsoft Azure、Google Compute Engine、Hetzner、Oracle Cloud、Scaleway、Tencent Cloud、Alibaba ECS 與 Vultr。新增的 systemd-imds-generator 在開機時自動偵測所在雲端環境並啟用對應服務單元。從雲端供應商取得的所有資料在匯入前均會完成測量（measured），確保可審計性。
Varlink 介面提供兩層查詢能力：低階欄位直接對映供應商原始 API 回應，高階 well-known 欄位則跨供應商統一命名，讓應用程式無需針對各雲端廠商個別適配。此設計讓雲端工作負載得以透過統一介面取得 Instance ID、網路介面、標籤等元資料，不受供應商差異影響。
Boot Secret 與 TPM 軟體回退
Boot Secret 機制解決了無硬體 TPM 環境下的金鑰材料問題：systemd-stub 從持久化 EFI 變數衍生一組秘密，並透過 initrd 中的 /.extra/boot-secret 路徑傳遞至使用者空間。規格明確要求應用程式以此秘密為基礎再衍生自身金鑰，而非直接使用原始值，確保不同應用之間的金鑰空間互相隔離。
同版本新增 systemd-tpm2-swtpm.service 作為軟體 TPM 回退方案，可透過核心參數 systemd.tpm2_software_fallback= 啟用。TPM 測量面亦有顯著強化：新增 systemd-pcrosseparator.service，在 PCR 0–7、9、12–14 注入分隔符，將韌體測量與主機測量區隔開來；systemd-stub 新增對 SMBIOS Type 1、Type 2 與 Type 11 的 PCR 1 測量支援。新增 ConditionSecurity=measured-os 單元條件，讓服務得以感知目前是否在 measured boot 環境下執行。
Live Update Orchestration 與 Kexec Handover
PID1 現在能在核心支援的情況下，透過 kexec 操作保留 FD Store 中的檔案描述符。設定 FileDescriptorStorePreserve=yes 的單元可讓具名記憶體描述符（目前限 memfd）跨 kexec 重開機存活，讓有狀態服務在核心熱更新後無需重建連線或快取。新增的 FileDescriptorStorePreserve=on-success 變體僅在服務成功退出時保留 FD Store，提供更精細的控制語義。
Varlink API 擴充
本版本大幅擴充 Varlink 介面體系。新增 io.systemd.Job 介面提供工作管理能力；io.systemd.Manager 獲得 PowerOff()、Reboot()、SoftReboot()、Halt()、Kexec() 等關機方法；新增 io.systemd.Shutdown 介面支援帶請求者識別的關機請求。systemd-hostnamed 的 Varlink 端點現在在早期開機階段 D-Bus 啟動前即可使用。
sd_varlink_set_sentinel()：簡化「more」旗標的回應處理sd_varlink_call_and_upgrade()/sd_varlink_reply_and_upgrade()：支援協定升級切換varlinkctl serve：可將任意指令包裝成 Varlink 伺服器- 每個 UID 的並發連線上限降至 128 個
破壞性變更
升級前需特別留意相容性破壞。systemd-nspawn 的 --user= 參數已更名為 --uid=（舊參數仍保留但標記棄用）；Varlink 介面的列舉值從連字號改為底線（例如 "tty-force" 更名為 "tty_force"）；udev 資料庫版本 0 支援已移除，意即無法從 v247 以前版本進行即時升級（live upgrade）。musl 最低版本需求從 1.2.5 提升至 1.2.6；libsystemd 不再保證與 libm 連結。
動態連結方面，libgnutls、libmicrohttpd、libcurl、libcrypto、libssl、libfdisk、libcryptsetup 等依賴全數改為 dlopen() 方式載入，各二進位檔案現在嵌入 ELF dlopen 元資料備註（ELF note）以利依賴發現工具分析，符合 UAPI 規格。服務管理器新增 ConditionFraction= 設定，可依機器 ID 雜湊值進行分批推送（staged rollout）；MinimumUptimeSec=（預設 15 秒）防止開機迴圈快速觸發重啟。
BPF 程式的協程化：核心層級暫停與恢復機制的設計挑戰
LWN.net · 2026-06-19
2026 年 5 月於克羅埃西亞薩格勒布舉辦的 Linux Storage, Filesystem, Memory-Management and BPF Summit（LSF/MM/BPF）中，核心開發者 Kumar Kartikeya Dwivedi 提出將 BPF 程式表達為協程（coroutine）的實驗性方案。這項工作試圖突破 BPF 的「執行到結束」（run-to-completion）限制，允許 BPF 程式在執行過程中暫停，稍後由核心恢復執行，使長時間運行的 BPF 工作邏輯得以線性表達。
原本的問題
BPF 的執行模型要求程式在啟動它的同一執行上下文中同步完成，不能讓出 CPU 或等待外部異步事件。對需要跨多個事件點收集狀態、或需等待 I/O 完成才能決策的場景，開發者目前必須將邏輯拆解為多個 BPF 程式，透過尾呼叫（tail call）銜接或借助 BPF ring buffer 與用戶空間協作。這兩種變通做法都大幅增加程式複雜度，且難以維護跨呼叫的局部狀態。
BPF 已有 sleepable 程式的概念，允許特定掛載點上的程式在受控環境進入睡眠，但 sleepable 語義受到嚴格限制，仍無法表達「暫停、等待某事件、再從同一位置繼續」的協程控制流。這個空缺在長時間追蹤、複雜安全策略以及需要等待網路回應的 BPF 程式中尤為明顯。
採用的方法
Dwivedi 的方案以協程的 suspend/resume 原語為核心：BPF 程式可在執行過程中 yield，將控制權歸還核心，並在稍後條件滿足時由核心排程器恢復執行。恢復點必須在 yield 前完整快照協程狀態，包括局部變數、暫存器內容與當前執行位置，這是實作上的主要挑戰。
在核心實作層面，此機制需要與 BPF 驗證器（verifier）深度整合：驗證器必須靜態分析哪些暫停點是安全的、協程狀態如何在記憶體中佈局，以及恢復執行時堆疊框架的重建方式。每個可暫停的 BPF 程式需配備一個對應的狀態結構（概念上類似核心 task_struct 中的執行緒上下文），用於在 yield 點完整封存執行環境。
協程化 BPF 程式的恢復機制設計為與現有 BPF 連結（link）和鉤子（hook）基礎設施相容，確保現有程式類型（如 XDP、tc BPF、kprobe）不受影響——協程語義僅對明確選擇此執行模型的程式類型生效，現有程式毋需任何修改。
影響範圍
此提案目前仍處於實驗性討論階段，尚未形成正式的 RFC 補丁系列提交至 bpf-next 樹，峰會討論是推動社群共識的前置步驟。一旦機制穩定，最直接的受益場景是需要跨封包追蹤連線狀態的網路過濾程式，以及需要等待異步響應的安全策略引擎，兩者都是現行 run-to-completion 模型難以優雅表達的典型案例。
協程模型將允許開發者以線性循序邏輯表達現在需要多個 tail call 才能實現的工作流，也可能讓某些目前只能在用戶空間處理的邏輯下沉至核心 BPF 層，減少上下文切換開銷。驗證器的複雜度預期顯著增加——如何在不犧牲 BPF 安全保證的前提下支援協程狀態的靜態分析，是後續實作的核心技術難點。
AUR 大規模供應鏈攻擊事件：逾 1,500 個孤兒套件遭植入 Rust 竊密程式與 eBPF Rootkit
The Register · 2026-06-15
2026 年 6 月 11 日，Arch User Repository（AUR）爆發大規模供應鏈攻擊，攻擊者系統性接管逾 1,500 個孤兒套件，透過篡改 PKGBUILD 檔案植入以 Rust 撰寫的多階段竊密程式。Arch Linux 維護團隊於 6 月 12 日發出官方警告，並於 6 月 15 日緊急停用新帳號註冊。Arch 官方核心倉庫（[core]、[extra]、[multilib]）因採用更嚴格的審核流程而完全未受波及。
漏洞機制
攻擊核心在於 AUR 的孤兒套件認養機制：AUR 允許任何用戶申請接管長期無人維護的套件（orphaned package）。攻擊者批量接管擁有既有用戶基礎的廢棄套件後，修改 PKGBUILD 中的 build() 或 package() 函式，或在 .install 鉤子腳本中插入惡意指令，在安裝期間靜默觸發惡意酬載下載與執行。
實際酬載透過三個 npm 套件傳遞：atomic-lockfile、js-digest、lockfile-js。這些套件在其 preinstall 腳本中觸發一個以 Rust 編譯的原生 Linux 可執行檔，此設計讓酬載繞過以程式碼靜態掃描為主的傳統偵測機制——PKGBUILD 本身的變更看似無害，實際惡意邏輯藏在外部 npm 依賴之中。6 月 12 日出現的第二波攻擊更引入 Bun 執行環境的安裝路徑，擴大感染面並增加分析難度。
惡意程式能力
Rust 酬載以多目標竊密為主要功能，系統性提取下列資料：
- Chromium 系與 Firefox 系瀏覽器的 cookie、session token 及自動填入資料
- SSH 私鑰與
known_hosts檔案 - 環境變數中的 GitHub token、npm token 與雲端服務憑證（AWS、GCP、Azure）
- Slack、Discord、Microsoft Teams 的本地 session 資料
- Docker / Podman 認證設定與 Kubernetes
kubeconfig - 加密貨幣錢包檔案與助記詞
在取得 root 權限的系統上，酬載進一步部署基於 eBPF 的 rootkit，利用 libbpf API（bpf_object__load、bpf_program__attach、bpf_map__pin）將惡意程式偽裝成合法核心執行緒，規避 ps、top 等標準行程監控工具的偵測。相關檔案以 scales.bpf.c 等名稱出現於分析報告中。
受影響版本與範圍
AUR 現有超過 107,000 個套件，此次確認或懷疑遭入侵的數量從最初約 400 個，在攻擊周末期間快速攀升至逾 1,500 個，佔整體規模約 1–2%。使用 yay、paru 等 AUR helper 工具的用戶受影響最直接，因為這些工具的預設設定通常不強制要求手動審閱 PKGBUILD，攻擊者正是藉此繞過用戶警覺。攻擊以 CI/CD 環境和開發者工作站為首要目標，因為這類系統的 SSH 金鑰和雲端憑證最具利用價值。
修補與緩解
Arch Linux 維護團隊採取了以下措施：撤銷所有惡意 PKGBUILD 提交、永久封禁相關攻擊者帳號、公告受影響套件清單，並暫停新帳號註冊（新用戶訪問 AUR 帳號建立頁面時出現 503 Service Unavailable）。後續改進措施討論中包括孤兒套件認養等待期、新帳號的提交審閱窗口，以及認養行為的異常偵測機制。
受影響用戶應立即執行以下步驟：
- 執行
pacman -Qm列出所有外部套件，與官方公告的受影響清單比對 - 審查 2026 年 6 月 10 日至 12 日間安裝或更新的 AUR 套件的 PKGBUILD git 歷史
- 全面輪換所有憑證：SSH 金鑰、API token、瀏覽器 session
- 使用
rkhunter或chkrootkit掃描 rootkit 殘留 - 在 AUR helper 中啟用強制 PKGBUILD 審閱提示（如
yay的--editmenu選項）
此事件暴露了 AUR 開放貢獻模型在孤兒套件治理上的系統性脆弱點：安全邊界的強度取決於最後一個活躍維護者離開的時間點，而非套件的安裝量或歷史信任程度。
原始來源：Arch Linux locks down AUR signups — The Register · 400+ AUR Packages Compromised — CyberSecurityNews · Atomic Arch Supply Chain Attack — Rescana