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 Enterprise Linuxを基盤とするRed HatのIn-Vehicle Operating Systemは、認証機関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 Part 6を評価フレームワークとし、既存ソフトウェアに対する信頼性獲得仕様であるISO/PAS 8926:2024に整合させています。統合者はこれらの前提条件を遵守する責任を負います。

安全モニタが整合性を担う。 大規模なLinuxベース機能自体を信頼するのではなく、結果をチェックし、異常時に安全状態へ移行させる、小規模でシンプル、高信頼性のコンポーネントを追加します。このモニタは小規模であるため、従来の方法で開発・認証が可能であり、高い整合性要件はLinuxからこのモニタへ移されます。これがmixed-criticalityパターンであり、しばしばリアルタイムOSが重要なループを1つのコアで処理し、Linuxが別のコアでリッチな機能を処理する形態が取られます。

干渉からの自由。 安全部分と非安全部分は、互いのメモリ、タイミング、実行を破壊しないように分離する必要があります。これは、ハードウェアとパーティショニングによって強制されます。コアの分離、メモリ保護・管理ユニット、またはXenのようなハイパーバイザ（ELISA内で安全関連の取り組みが活発に進められている）が用いられます。

継続的な認証。 Linuxは常に変化するため、認証は一度きりのイベントではありえません。証拠と論証はコードベースの変更に応じて維持され、ベンダーは「一度認証された」ではなく「継続的に認証されている」と表現しています。

ELISAが構築しているもの

ELISAの貢献は、単一企業が単独で再構築したくない共通の基盤です。ワーキンググループは自動車、医療機器、航空宇宙、横断的なシステム・エンジニアリングプロセスをカバーし、オープンツールとドキュメントを提供しています。カーネル構成の記述方法、要件からテストへのトレーサビリティ、安全論証が依存するカーネル機能・サブシステムの特定方法、エンジニアリングプロセスの記録方法などが含まれます。最近のコミュニティ活動には、Xenハイパーバイザの安全分析や医療ソフトウェア向けオープンソース品質管理システムが含まれます。プロジェクトは拡大を続けており、2026年を通じて新たな産業・学術メンバーが参加しています。

組み込み・カーネルエンジニアにとっての意味

Safety-critical Linuxは、カーネルエンジニアリングと安全エンジニアリングの中間に位置するスキルセットへの需要を生み出しており、現在その両方を備えた人材は極めて少ないのが実情です。具体的に価値のある能力は以下の通りです。パーティショニングやハイパーバイザを用いた干渉からの自由の設計；安全モニタのアーキテクチャ設計により、整合性要件をシステム全体ではなく小規模コンポーネントに集中させること；ビルドの再現性と監査可能性を確保するための厳格なカーネル構成と要件トレーサビリティ；ASIL分解とAssumptions of Useの理解；RTOSとLinuxが1つのSoCを共有するmixed-criticality設計の運用。カーネルの知識はベースラインであり、その周囲で防御可能な安全論証を構築できる知識こそが希少な部分です。両方を学ぶ意欲のあるエンジニアにとって、これは今後10年で報われる、より持続可能な専門分野の一つです。

Key takeaways

  • Safety-critical Linuxはすでに製品で実用化されています。Red HatのIn-Vehicle OSは2025年にISO 26262 ASIL-BをSEooCとしてexidaから認証取得しました。
  • カーネル全体を従来の要件駆動Vモデルで認証することはできません。規模が大きすぎ、流動的であり、そのようなプロセスで書かれたものではないためです。
  • 現実的な道筋は、定義された構成とAssumptions of Use、小規模な安全モニタによる整合性の担保、パーティショニングによる干渉からの自由、継続的な認証です。
  • 安全はセキュリティとは異なる分野であり、規格（ISO 26262、IEC 62304、DO-178C、IEC 61508）も証拠も異なります。
  • 新たに求められる希少なスキルセットは、Linux内部だけでなく、Linuxを取り巻く安全アーキテクチャです。

Frequently asked questions

Linuxカーネル自体をISO 26262で認証することは可能ですか？
全体として従来の意味で認証することはできません。認証されるのは、定義された文脈に対する特定の構成であり、文書化されたAssumptions of Useを持つSafety Element out of Contextとして、監視とパーティショニングによって支えられます。Red HatのIn-Vehicle OSはASIL-Bでこの方法で認証されました。

Safety-critical Linuxは、セキュアまたは強化されたLinuxと同じですか？
いいえ。セキュリティは攻撃者への耐性を問うもので、安全はハードウェア障害やソフトウェアバグを含む何らかの故障時に安全状態へ到達できるかどうかを問います。異なる規格と証拠を用い、強化されたシステムであっても安全でない場合があります。

安全モニタとは何ですか？なぜ重要ですか？
Linuxベースの機能をチェックし、障害時に安全状態へ移行させる、小規模でシンプル、高信頼性のコンポーネントです。小規模であるため従来の方法で認証可能であり、高い整合性要件を大規模なLinuxシステムから切り離すことができます。

ELISAとは何ですか？
Linux FoundationのEnabling Linux In Safety Applicationsプロジェクトです。メンバーは、Linuxベースの安全クリティカルシステムを構築・認証するための共通ツールとプロセスを構築し、自動車、医療、航空宇宙分野の認証機関や規格団体と連携しています。

Further reading

Originally published on TECH VEDA.