「OpenHCL」機密VMを実現する新しいオープンソースのパラバイザー
この記事の内容
- Microsoftがオープンソースのパラバイザー「OpenHCL」を公開しました
- パラバイザーとは、ゲストVM内でOSよりも高い特権レベルで動作し、仮想化サービスを提供する実行環境です
- OpenHCLを使うことで、古いOSでもコンフィデンシャルVM（機密VM）として実行できるようになります
- Azureではすでに採用されており、直近1ヶ月で150万台以上のVMがOpenHCL上で稼働しています
- Intel TDX・AMD SEV-SNPなど複数の機密コンピューティングプラットフォームをサポートしています
仮想化とコンフィデンシャルコンピューティングの背景
クラウドコンピューティングの黎明期から、仮想化技術はIaaS（Infrastructure as a Service）の中心的な役割を担ってきました。クラウド基盤のハードウェアがどれだけ進化しても、その恩恵を受けながらVMを継続稼働できるのが仮想化の強みです。
そこに加わったのが「コンフィデンシャルコンピューティング」という概念です。クラウド上で稼働するVMのセキュリティをさらに大幅に向上させる技術であり、ホスティング事業者に対してもVMの内部を保護することができます。
ただし、コンフィデンシャルコンピューティングを活用するにはトレードオフがあります。より安全な環境を得るためには、対応した新しいOSへのアップグレードが必要になるケースが多く、ハイパーバイザーが提供できる仮想化サービスの豊かさが制約されることもあります。新しいコンフィデンシャルコンピューティング技術が登場するたびに、対応OSへの更新を求められるという負担が生じるのです。
パラバイザーとは何か
この課題に対してMicrosoftが採用したアプローチが「パラバイザー（Paravisor）」です。
パラバイザーは、ゲストVM内においてゲストOSよりも高い特権レベルで動作する実行環境です。OSとは独立して存在し、ゲストに対してデバイスエミュレーションや仮想化サービスを提供します。
イメージとしては、ゲストVMの中にもう一つ仮想化を支える基盤が存在するような構造です。ハイパーバイザーとは異なりますが、ゲストVMの下支えとなる層として機能します。
パラバイザーはコンフィデンシャル環境・非コンフィデンシャル環境のどちらでも動作可能です。コンフィデンシャル環境で動作する場合、その特権レベルはコンフィデンシャルコンピューティングのハードウェアプラットフォームによって強制されます。
Virtual Secure Mode（VSM）
Microsoftの仮想化スタック上でパラバイザーを動作させるために使われているのが「Virtual Secure Mode（VSM、仮想セキュアモード）」です。
VSMはWindowsのセキュリティ機能の基盤となる技術であり、以下のような機能を支えています。
- Device Guard
- Credential Guard
- 仮想TPM
- シールドVM
コンフィデンシャルコンテキストで実行する場合、VSMはハードウェアプラットフォームに依存しない方法で適切に実施することが可能です。
OpenHCLとは
Microsoftは業界初のパラバイザーを開発し、Azureのお客様に提供してきました。その成果をオープンソースとして公開したものが「OpenHCL」です。GitHubでは「OpenVMM」という名称でも公開されています。
OpenHCLは以下の機能を提供します。
デバイスエミュレーション
VTPやシリアルなど、標準的なエミュレートデバイスのセットを提供します。ゲストOSは標準インターフェイス経由でこれらのデバイスを利用できるため、OS自体に変更を加える必要がありません。
デバイストランスレーション（変換）
NVMeなどのデバイスを標準インターフェイス（PVSI：Para Virtualization Standard Interface）を通じて提供します。
診断サポート
従来のデバッグ方法では難易度が高かった機密VM環境での診断を、標準的なアーキテクチャインターフェイスを通じて実施できるようにします。
これらの機能により、WindowsやLinuxの古いバージョンも、機密コンピューティングプラットフォーム上で実行できるようになります。
OpenHCLのアーキテクチャ
OpenHCLはいくつかのコンポーネントで構成されていますが、最も重要なのはOpenVMMと呼ばれるモジュール式のクロスプラットフォーム仮想マシンモニター（VMM）です。OpenVMMはRust言語で書かれています。
アーキテクチャを図で整理すると、以下のような構造になります。
OpenHCLの内部では、VMMがユーザーモードプロセスとして動作し、割り当てられたデバイスのゲストサポートとデバイス変換サポートを提供します。コンフィデンシャル・非コンフィデンシャルのゲストに対して共通のVMMを使用しつつ、それぞれに適したサービスを提供できる点が優れています。
その他のコンポーネントとしては、ブートローダーと小さなカスタムLinuxカーネルがあります。このカーネルはKconfigによってバイナリサイズとランタイムのRAM使用量を最小化するよう設計されています。
対応プラットフォーム
OpenHCLは以下のプラットフォームをサポートしています。
- アーキテクチャ：x86-64（AMD64）
- 機密コンピューティングプラットフォーム：
- Intel TDX
- AMD SEV-SNP
- AMD CCA
- ホスト：KVM
なぜWindowsにはパラバイザーが必要なのか
「なぜWindowsをネイティブで完全にコンフィデンシャルなゲストとして動かさないのか」という疑問に対して、Microsoftは以下のように説明しています。
AzureでコンフィデンシャルVMの開発を始めた当初のハードウェアでは、Windowsを完全対応させることができませんでした。その理由は主に2点です。
APICエミュレーションの問題：Windowsは割り込みコントローラー（APIC）のエミュレーションを必要としており、これは従来ハイパーバイザー側で行う必要がありました。Linuxは割り込み管理をAPICに直接依存しない設計ですが、Windowsは依存しています。現在はAPIC仮想化をサポートするハードウェアも登場しましたが、当時はサポートされていませんでした。
仮想TPMの問題：Windowsはセキュリティ機能のためにTPMに依存しており、コンフィデンシャルVM環境では仮想TPMの実装が必要になります。これをパラバイザーに実装することが求められました。
これらの理由から、今後もWindowsゲストはパラバイザー経由でサポートする方針が継続される予定です。
一方でLinuxは、割り込み管理もTPMもパラバイザーへの依存が不要な設計になっているため、将来的にはパラバイザーに依存しないネイティブなコンフィデンシャルVMアプローチも登場してくる見込みです。
COCONUT-SVSMとの違い
「COCONUT-SVSM（Secure VM Service Module）」というコンフィデンシャルコンピューティング関連技術も存在します。これはシークレットの保存や仮想化サービスの提供を通じてコンフィデンシャルVMゲストの利便性を高めるものです。
OpenHCLとの違いは解決する問題の違いにあります。
| 項目 | COCONUT-SVSM | OpenHCL |
|---|---|---|
| 対象ゲスト | 新しいインターフェイスに完全対応したゲストOS | 既存の標準インターフェイスを使う古いOSも含む |
| 主な手法 | 新しいインターフェイス | 既存の標準アーキテクチャインターフェイス |
| デバイス提供 | デバイスエミュレーションを使わないケースも | デバイスエミュレーション・トランスレーションを活用 |
なお、将来的にはCOCONUT-SVSMをOpenHCLと組み合わせて使う可能性も示されています。
Azureでの利用実績
OpenHCLはすでにAzureで実運用されています。新しいAzureの「BOOST SKU」で採用されており、将来的にはAzureのコンフィデンシャルVM SKUでも使用される予定です。
直近1ヶ月だけで150万台以上のVMがAzure上のOpenHCL環境で稼働しており、クラウドスケールでの実績が示されています。
まとめ
OpenHCLは、Microsoftがオープンソースとして公開した新しいパラバイザーです。ハイパーバイザーとは異なり、ゲストVMの内部でゲストOSよりも高い特権レベルで動作し、デバイスエミュレーションや仮想化サービスを標準インターフェイス経由で提供します。
最大のメリットは、古いWindowsや古いLinuxのバージョンであっても、OSを更新することなくコンフィデンシャルVM（機密VM）として実行できる点です。クラウド基盤側のハードウェアが進化しても、ゲストOSはそのままで新機能の恩恵を受け続けられるアーキテクチャが実現されています。
Azureではすでに本番運用が始まっており、Intel TDXやAMD SEV-SNPなど複数の機密コンピューティングプラットフォームに対応しています。レガシーな環境をクラウドに移行する際のセキュリティ確保という観点からも、注目すべき技術といえるでしょう。