Cover image for Safety-Critical Linux: What Certifying It Actually Takes

Raghu Bharadwaj

Safety-critical Linux 指的是在故障可能造成人員傷害的場景中執行 Linux，例如汽車、工業機器人與醫療裝置。 您無法以小型安全控制器的方式為整個核心取得認證，因此產業採用不同的做法：將特定 Linux 配置以「Safety Element out of Context」形式認證，並記載其使用假設，再搭配小型高完整性監控器與硬體分割，防止故障擴散，並隨著程式碼變更持續維護認證。對嵌入式工程師而言，這項轉變創造了以安全架構為基礎的新技能，而非僅限於核心程式碼。

在 Linux 過去的發展歷程中，它從未被放在可能傷害人的產品區塊。它負責儀表板而非煞車系統；負責醫院顯示器而非輸液泵的劑量控制迴路。這條界線如今正在移動。軟體定義汽車、醫療機器人與工業自動化希望在整個裝置上使用單一且功能強大的作業系統，而 Linux 正逐漸成為這個選擇。Safety-critical Linux 的目標是在不降低安全標準的前提下，讓 Linux 承擔這些角色。本文說明為什麼這件事困難、實際的做法，以及這項轉變對嵌入式與核心工程師的意義。

為什麼 safety-critical Linux 突然成為現實

最清楚的證據是一張證書。2024 年至 2025 年，Red Hat 的 In-Vehicle Operating System 以 Red Hat Enterprise Linux 為基礎，獲得 exida 認證機構針對 ISO 26262:2018 ASIL-B 的分階段功能安全認證，並於 2025 年正式上市。功能安全標準定義了不同等級的完整性：汽車領域的 ISO 26262 從 ASIL-A 到最嚴格的 ASIL-D，IEC 62304 適用於醫療裝置軟體，DO-178C 涵蓋航空系統，而 IEC 61508 則是工業基礎標準。幾年前，通用 Linux 發行版取得任何汽車 ASIL 等級的認證聽起來似乎不太可能。

這項里程碑背後是社群共同努力。Linux Foundation 的 ELISA 專案（Enabling Linux In Safety Applications）匯集汽車、半導體與工業成員，共同定義建置與認證 Linux 基礎安全關鍵系統的工具與流程，並直接與認證機構及標準組織合作。

💡 Key insight: 問題已從「Linux 能否安全？」轉變為「在哪個定義好的配置、哪個情境，以及搭配什麼監控，我們才能提出安全論證？」這種重新框架正是近期認證得以實現的原因。

為什麼無法以傳統方式為 Linux 取得認證

傳統安全認證假設的開發流程是 Linux 從未遵循的。經典安全元件依照需求導向的 V 模型建置：每個需求皆有記載，並追溯至設計、程式碼與測試，通常搭配 MC/DC 等結構涵蓋率。這對數萬行、專為特定用途撰寫的程式碼是可行的。Linux 核心則有數千萬行程式碼，由數千人貢獻，每週都在變更，而且從未依照完整、可追溯的需求集撰寫。此外，也無法保證一個元件發生異常時，不會破壞其他元件。

因此，您無法簡單地將整個核心送入 V 模型審核並發出證書。Safety-critical Linux 的現實途徑是改變您所認證的對象以及論證方式。

💡 Key insight: 安全不等於資安。資安關注攻擊者是否能入侵；安全則關注系統在發生故障（包含硬體故障與自身錯誤）時是否能進入安全狀態。一個系統可能已強化，但仍然不安全，而所使用的標準、證據與技能也不同。

實際的做法

Safety-critical Linux 透過多種技術達成，而非「證明整個核心正確」。

Safety Element out of Context (SEooC)。 廠商並非為通用 Linux 取得認證，而是針對假設情境認證特定配置，並記載必須成立的 Assumptions of Use。Red Hat 的認證正是採取此途徑：它是針對預先定義目標硬體的 ASIL-B SEooC，使用 ISO 26262 第 6 部分作為評估架構，並符合 ISO/PAS 8926:2024（用於對既有軟體建立信心的規範）。整合者則負責遵守這些假設。

安全監控器承擔完整性。 設計中加入小型、簡單、高完整性的元件，負責檢查結果並在發生問題時強制進入安全狀態，而非信任大型 Linux 功能。由於監控器體積小，可依傳統方式開發與認證，沉重的完整性需求因此從 Linux 轉移到這個元件。這就是混合關鍵性模式，通常由即時作業系統在一個核心上處理關鍵迴路，而 Linux 在另一個核心上執行豐富功能。

不受干擾。 安全與非安全部分必須防止相互破壞記憶體、時序與執行。這透過硬體與分割來強制執行：獨立核心、記憶體保護或管理單元，或如 Xen 等虛擬化管理程式，其安全工作是 ELISA 內部的活躍議題。

持續認證。 由於 Linux 不斷變更，認證無法是一次性事件。證據與論證會隨著程式碼庫移動而維護，這也是廠商將其產品描述為「持續認證」而非「一次性認證」的原因。

ELISA 正在建置什麼

ELISA 的貢獻是單一公司不願獨自重建的共享基礎。其工作小組涵蓋汽車、醫療裝置、航太，以及跨領域系統與工程流程議題，並產出開放工具與文件：描述核心配置的方式、需求追溯至測試、分析安全論證依賴的核心功能與子系統，以及記錄工程流程本身。最近的社群工作涵蓋 Xen 虛擬化管理程式的安全分析，以及醫療軟體的開放原始碼品質管理系統。該專案正在擴展，2026 年有新的工業與學術成員加入。

對嵌入式與核心工程師的意義

Safety-critical Linux 創造了介於核心工程與安全工程之間的技能需求，目前同時具備兩者的人非常少。這些有價值的技能具體包括：以分割與虛擬化管理程式設計不受干擾；架構安全監控器，使完整性需求落在小型元件而非整個系統；嚴謹的核心配置與需求追溯，使建置可重現且可審核；理解 ASIL 分解與 Assumptions of Use；以及執行混合關鍵性設計，讓 RTOS 與 Linux 共用單一 SoC。了解核心是基礎；了解如何圍繞核心提出可辯護的安全論證才是稀缺的部分。對於願意同時學習兩者的工程師而言，這是未來十年值得投入的持久專長之一。

Key takeaways

  • Safety-critical Linux 已在實際產品中實現：Red Hat 的 In-Vehicle OS 於 2025 年取得 ISO 26262 ASIL-B 認證，由 exida 以 Safety Element out of Context 形式認證。
  • 您無法以傳統需求導向 V 模型為整個核心取得認證；它太大、太流動，且從未依照該流程撰寫。
  • 可行的途徑是定義配置加上 Assumptions of Use、小型安全監控器承擔完整性、透過分割達成不受干擾，以及持續認證。
  • 安全是不同於資安的學科，使用不同標準（ISO 26262、IEC 62304、DO-178C、IEC 61508）與不同證據。
  • 新興且稀缺的技能是圍繞 Linux 的安全架構，而非僅限於 Linux 內部。

Frequently asked questions

Can the Linux kernel itself be certified to ISO 26262?
無法以傳統方式為整個核心取得認證。取得認證的是針對定義情境的特定配置，以 Safety Element out of Context 形式並記載 Assumptions of Use，搭配監控與分割來支援。Red Hat 的 In-Vehicle OS 正是以此方式取得 ASIL-B 認證。

Is safety-critical Linux the same as a secure or hardened Linux?
不是。資安關注抵抗攻擊者；安全關注在發生故障（包含硬體故障與軟體錯誤）時進入安全狀態。它們使用不同標準與不同證據，而一個已強化的系統仍可能不安全。

What is a safety monitor and why does it matter?
它是一個小型、簡單、高完整性的元件，負責檢查 Linux 功能並在發生故障時強制進入安全狀態。由於體積小，可依傳統方式取得認證，從而將沉重的完整性需求從大型 Linux 系統轉移。

What is ELISA?
Linux Foundation 的 Enabling Linux In Safety Applications 專案。其成員建置用於建立與認證 Linux 基礎安全關鍵系統的共享工具與流程，並與汽車、醫療與航太領域的認證及標準機構合作。

Further reading

Originally published on TECH VEDA.