記事一覧

個別統合なしでシリコンをAGELAIOSノードへ届けるProvider Pack

AGELAIOS

エコシステム

マニフェストから有効化までのProvider Packの5段階ライフサイクル。ソフトウェアフォールバックを強調。

競争力のあるNPU、暗号アクセラレーター、ソフトウェア無線を持つ中規模メーカーを想像してください。2つのプログラムオフィスが採用を望んでいます。しかし、それぞれに既存のインテグレーター、ドライバーモデル、独自のセキュリティプロセスがあります。メーカーは購入者ごとに独自SDK、専用移植、サポート契約を求められます。数か月後もシリコンは研究室にあり、何年も前に統合費用を支払っていた大手サプライヤーが両方の採用枠を得ています。

戦術エッジシステムでは、これが標準的な経路です。ハードウェアの到着は遅れ、統合によって双方が固定され、プログラムごとにゼロから始めます。顧客ごとの個別統合へ資金を投じられないメーカーにとって、このコストは決定的です。優れたシリコンが、重要なプログラムの外に留まります。

AGELAIOSは代わりに標準経路を提供します。Provider Pack、略称PCKは、メーカーがインテグレーターごとの二者間交渉なしに、シリコンをAGELAIOSインスタンスへ公開するための納入単位です。この記事では、パックの内容、参照リポジトリのエミュレートNPUパックを使って実機なしで構築する方法、フリート内でのライフサイクル、そして必須のソフトウェアフォールバックが運用者だけでなくメーカーにも利益をもたらす理由を説明します。

ノードから見た問題

AGELAIOSノードは、署名され分離されたモジュールを実行します。推論、暗号高速化、波形を必要とするモジュールは、下層にどのチップがあるかを知る必要がありません。マニフェストで必要なケイパビリティを宣言し、ノードが現在保有するケイパビリティと照合します。

この照合を機能させるには、ハードウェアが正規化された形で自己を提示しなければなりません。それがPCKの役割です。メーカーがシリコンを、私的契約下の1社のインテグレーターではなく、すべてのAGELAIOSインスタンスから見えるようにする仕組みです。

宣言型インターフェースを通じてワークロードへハードウェアリソースを公開する考え方は、このプロジェクト独自ではありません。Kubernetesのデバイスプラグインは、コンテナ基盤で同じ原則に従います [5]。OCI仕様も同様に、ソフトウェアの納入単位を標準化します [4]。PCKは、防衛分野で必要な証拠、アテステーション、オフライン運用能力を追加します。

4つの要素でパックを構成する

PCKは署名済みアーカイブです。4つの要素を含み、いずれも省略できません。

マニフェスト

マニフェストは、パックのメーカー、対象ハードウェア、バージョン、対応ファームウェアリビジョンを宣言します。また、プラットフォームのケイパビリティ語彙を用いて、公開するハードウェア機能を宣言します。代表例は、対応形式を伴う推論、暗号プリミティブの高速化、利用可能な波形です。各ケイパビリティについて、ソフトウェアフォールバックを指定します。モジュールと同様、暗黙の要素はありません。マニフェストにないケイパビリティは、ノードにとって存在しません。

オンボードセルフテスト

パックは独自の検証手順を保持します。外部ツールなしでノード上から実行し、ハードウェアの存在、ファームウェアバージョンの一致、既知テストベクトルに対する応答を確認します。セルフテストは有効化時と、運用者が要求した時に実行されます。失敗するとケイパビリティはソフトウェアフォールバックに留まり、相違を記録します。ノードはアクセラレーターが正常だと推測しません。問いかけ、その答えを保持します。

再現可能な立会いセッション

メーカーは、ハードウェアへ投入した入力と、返るべき出力を記録した参照セッションを作成します。そのセッションは、ハードウェアなしではパックのエミュレーションに対して、ハードウェアありでは実シリコンに対して再実行できます。インテグレーターと評価者は、両環境で実証された同じ挙動という、安定した比較対象を得ます。

立会いセッションは保証にも役立ちます。フリートを評価する当局は、メーカーの研究室へ依存せず、参照ノードでセッションを再生し、結果を保存できます。主張はベンダーデモのスライドではなく、第三者が実行できる成果物になります。

メーカーの署名済みアテステーション

メーカーはパックへ署名することで、マニフェストが自社ハードウェアを記述し、セルフテストが自社作成であり、立会いセッションが自社研究室から得られたことを証明します。この署名には、フリートへのパック導入を承認するインスタンス署名が追加されます。置き換えるものではありません。2つの判断は別です。メーカーは出荷するシリコンに責任を持ち、運用者は特定フリートへそのシリコンを導入する判断に責任を持ちます。

ハードウェアがTrusted Computing Group仕様に準拠したアテステーションコンポーネントを備える場合、パックはアテステーションをプラットフォームの測定済み状態へ結び付けることもできます [3]。これはシリコンが対応する場合に利用でき、すべてのアクセラレーターに仮定するものではありません。

エミュレートNPUパックが実行可能な手本になる

参照リポジトリには、エミュレートNPU向けの完全なPCKが含まれます。記入済みマニフェスト、動作するセルフテスト、付属の立会いセッション、署名チェーン例を備えたテンプレートです。専用ハードウェアなしに、プラットフォームのエミュレート済みx86-64およびARM64ノード上で動作します。

この例は2つの対象に役立ちます。メーカーにとっては出発点です。パックをクローンし、エミュレーションを実ドライバーへ置き換え、構造を保ちます。他の関係者にとっては再現可能な証拠です。検証、署名、有効化、フォールバックから成るPCKの全経路をエミュレータで実証できます。参照リポジトリの約930件の自動テストは、他の経路と同様にこの経路も対象としています。

構築経路は4段階に要約できます。

  1. リポジトリ内のエミュレートNPUパックから始め、エミュレートされたノード上で立会いセッションを再生し、完全な経路が動作する様子を確認します。
  2. 実ハードウェア用マニフェストを記述します。公開するケイパビリティをプラットフォーム語彙で宣言し、それぞれにソフトウェアフォールバックを指定します。
  3. エミュレーションを実ドライバーとセルフテストに置き換え、シリコン上で立会いセッションを記録します。
  4. パックへ署名し、インスタンスのストアへ提出します。ストアは自身のポリシーに従って承認します。

公開ツールチェーンは、その順序を直接提供します。

agelaios pck new npu-example --from emulated-npu
agelaios pck test
agelaios pck sign --key ./keys/provider

期待される結果は具体的です。セルフテストが成功し、立会いセッションが再生され、アテステーションがマニフェストを対象とします。どの段階もPenrose Tacticalを経由しません。メーカーは公開仕様に対して開発し、独自に判断するインスタンスへ納入します。

フリート内でのパックのライフサイクル

承認済みパックはインスタンスストアへ入り、モジュールと同様にTUF（The Update Framework）リポジトリを通じて配布されます。同じ署名者ロール、侵害されたリポジトリへの同じ耐性、同じ失効経路を使用します。メーカーが提供終了したパック、またはファームウェア脆弱性の発見後に運用者が失効させたパックは、通常の更新を通じてフリートから除かれます。影響を受けるケイパビリティは、ソフトウェア相当機能へフォールバックします。その後、ノード上のパックは3つの仕組みで管理されます。

fs-verityによる完全性

パックのファイルはfs-verityで封印されます。Linuxカーネルは、インストール時にルートを固定したハッシュツリーに対して、読み取りごとに検証します [1]。インストール後であっても、ディスク上でパックが変更されると、変更ブロックは提供されず読み取り不能になります。完全性はインストール時に一度確認するチェックサムではなく、その後のすべての読み取りに備わる性質です。

IMAによる測定

Integrity Measurement Architectureは、実行時にパックの実行ファイルとライブラリを測定し、その測定ログを保持します。ログはノードのTPMへアンカーできます [2][3]。インスタンス運用者は、何がインストールされたかだけでなく、実際に何がノード上で実行されたかを後から証明できます。この区別は監査で重要です。インストール記録は意図を記述し、IMAは実行されたものを記述します。

サービスを止めない有効化

パックの有効化は、稼働中ノードを前提に設計されています。セルフテストでハードウェア機能を検証し、その後ノードのカタログへ公開します。ソフトウェアフォールバックを利用していたモジュールは、ノードを再起動せずハードウェア高速化へ切り替わります。無効化は逆順です。機能を中断せずフォールバックへ戻ります。

成熟度についての率直な説明はここに必要です。実シリコンとの統合は現在、試行キャンペーン中です。実ARM64ボード上のキャンペーンはツール化済みで、失敗を含め、得られた結果を順次公開します。リポジトリが今日実証できるのはエミュレート経路です。シリコン経路は、キャンペーンが測定する対象です。

必須ソフトウェアフォールバックが販売上の強みにもなる理由

プラットフォームの規則は厳格です。PCKが公開するすべてのハードウェアケイパビリティには、縮退したソフトウェア相当機能が必要です。フォールバックを宣言しないパックはストアへ入りません。「縮退」は率直に表現しています。ソフトウェア推論は遅く、ソフトウェア暗号はプロセッサー時間を消費し、ソフトウェア波形は対応範囲が狭くなります。それでも機能自体は提供されます。

運用者の観点からは、理由は明白です。シリコンが故障したノードや、サプライヤーが消滅したフリートも、縮退モードで稼働を続けます。これはプラットフォームの他の部分と同じ管理された縮退の考え方です。

フォールバックは、競争にも構造的な影響を与えます。異なるメーカーの2つのパックがプラットフォーム語彙上で同じケイパビリティを公開すれば、モジュールから見て置換可能です。運用者はモジュールに触れず第2のシリコン供給元を認定し、同じ立会いセッションで両方を比較し、フリート内で混在させられます。ケイパビリティ語彙は、あらゆる開放市場における標準インターフェースの役割を果たします。競争の焦点を統合から性能へ移します。

メーカーの観点では、理由は分かりにくいかもしれませんが、明言する価値があります。必須フォールバックはメーカーの顧客も守り、だからこそハードウェアを購入可能なものにします。防衛分野の購入者は、あらゆる依存関係をリスクとして扱います。ソフトウェア上の退避手段がないハードウェアは、強い依存関係です。契約条項、エスクロー、不信を招きます。既存のソフトウェアフォールバックを高速化するハードウェアは、単一障害点ではなく性能向上です。

したがって、PCKは商業上の負担を反転させます。ハードウェアは加速しますが、機能成立の条件にはなりません。メーカーが売るのは拘束ではなく利得であり、顧客は立会いセッションを手に、シリコンとソフトウェアフォールバックを再現可能な形で比較できます。

プログラムオフィスへ提示すべき提案はこれです。次の購入者向けに一から構築し直す私的SDKではありません。公開仕様に基づく署名済みパックであり、フリートが承認、配布、失効、フォールバックできるものです。立会いセッションを再生し、自社シリコンにふさわしい統合モデルか判断してください。

参考文献

  1. Kernel.org, “fs-verity: read-only file-based authenticity protection”, 2024, https://www.kernel.org/doc/html/latest/filesystems/fsverity.html
  2. Linux IMA Project, “Integrity Measurement Architecture (IMA) Wiki”, 2024, https://sourceforge.net/p/linux-ima/wiki/Home/
  3. Trusted Computing Group, “TPM 2.0 Library Specification”, 2019, https://trustedcomputinggroup.org/resource/tpm-library-specification/
  4. Open Container Initiative, “OCI Image Format Specification”, 2024, https://github.com/opencontainers/image-spec
  5. The Kubernetes Authors, “Device Plugins”, 2024, https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/