さらば平文PXE、UEFI HTTPSブートでネットワーク起動を暗号化せよ

6月12日、Jean-Tiare Le Bigot氏が「Introduction to UEFI HTTP(S) boot with Qemu/OVMF」と題した記事を公開した。

インターネット経由でサーバーを起動する—そんなニーズが高まる現代において、従来のPXEブートは深刻なセキュリティホールとなっている。平文通信、署名なし、中間者攻撃への無防備。一方で、最新のUEFI環境では、HTTPS証明書による暗号化ブートが既に利用可能だ。本記事では、Qemu/OVMF環境でUEFI HTTP(S)ブートを実装する具体的手法を紹介する。

なぜ今、PXEから脱却する必要があるのか

PXE（Preboot eXecution Environment）は1990年代から使われてきたネットワークブート技術だが、現代の要求には適さない問題を抱えている。

セキュリティの脆弱性が最大の課題だ。PXEはDHCPとTFTPという平文プロトコルに依存しており、ブートイメージの改ざんや盗聴を防ぐ仕組みがない。クラウド時代にインターネット経由でサーバーを起動する場面では、この脆弱性は致命的だ。

加えて、運用面での課題も深刻である。DHCPサーバーの設定は複雑で、TFTPサーバーの高可用性確保も困難だ。一方、現代のWeb技術スタックでは、HTTPS（TLS証明書による認証・整合性・機密性）とCDNによる高可用性が標準化されている。

幸い、最新のUEFIベースシステムの多くはHTTP(S)ブートをサポートしている。UEFI仕様書では、HTTP(S)によるネットワークブートが標準化されており、セキュアブートとの組み合わせも可能だ。

実装の第一歩：HTTPブートから始める

Le Bigot氏は、netboot.xyzのsnponly版（http://boot.netboot.xyz/ipxe/netboot.xyz-snponly.efi）を例に、段階的な実装を進めた。netboot.xyzは、様々なLinuxディストリビューションやユーティリティをネットワーク経由でブートできるオープンソースプロジェクトだ。

最初の試行では、OVMF（Open Virtual Machine Firmware：QemuやKVM向けのオープンソースUEFI実装）の最小構成を使用した：

qemu-system-x86_64 \
    -drive if=pflash,format=raw,readonly=on,file=/usr/share/OVMF/OVMF_CODE_4M.fd \
    -nic user,bootfile=http://boot.netboot.xyz/ipxe/netboot.xyz-snponly.efi \
    -nographic

しかし、この構成では以下のエラーでブートに失敗した：

BdsDxe: No bootable option or device was found.
BdsDxe: Press any key to enter the Boot Manager Menu.

乱数生成器：ネットワークスタックの隠れた依存関係

失敗の原因は、OVMFのネットワークスタックに乱数生成器デバイスが必須だったことだ。イーサネットの衝突回避からTLS、DHCP自体まで、ネットワークプロトコルのほぼ全層で乱数が必要となる。

この依存関係は、EDK II（Intel主導のUEFI実装プロジェクト）のNetworkPkg/Library/DxeNetLib/DxeNetLib.infで明示的に宣言されている：

[Depex]
  gEfiRngProtocolGuid

解決策は、Qemuコマンドラインに乱数生成器デバイスを追加することだった：

qemu-system-x86_64 \
    -device virtio-rng-pci \
    -drive if=pflash,format=raw,readonly=on,file=/usr/share/OVMF/OVMF_CODE_4M.fd \
    -nic user,bootfile=http://boot.netboot.xyz/ipxe/netboot.xyz-snponly.efi \
    -nographic

これで約1分15秒後にnetboot.xyzが正常に起動した。

ブート時間の劇的改善：1分15秒から5秒へ

1分以上の起動時間は実用的ではない。UEFIネットワークスタックは以下の順序で試行する：

IPv4 PXE（HTTP URLが無効でTFTP参照が期待される）
IPv6 PXE（IPv6未設定のため失敗）
IPv4 HTTP（ここで成功）
IPv6 HTTP（次の試行候補）

OVMFの-fw_cfgフラグを使用してレガシーPXEを無効化することで、起動時間を約5秒まで短縮できた：

qemu-system-x86_64 \
    -device virtio-rng-pci \
    -drive if=pflash,format=raw,readonly=on,file=/usr/share/OVMF/OVMF_CODE_4M.fd \
    -nic user,bootfile=http://boot.netboot.xyz/ipxe/netboot.xyz-snponly.efi \
    -fw_cfg name=opt/org.tianocore/IPv4PXESupport,string=no \
    -fw_cfg name=opt/org.tianocore/IPv6PXESupport,string=no \
    -nographic

本命のHTTPS化：「s」一文字の追加が困難な理由

HTTPからHTTPSへの移行は、単純にURLの「http://」を「https://」に変更するだけでは実現できなかった。両方の方式でタイムアウトエラーが発生した。

Le Bigot氏はEDK IIのデバッグログ機能を活用して原因を特定した。Ubuntuに標準搭載されているのはRELEASEビルドのため、DEBUG版ファームウェアを自分でビルドする必要があった。

デバッグの結果、根本的な問題が判明した：CA証明書が提供されておらず、OVMFにはWebブラウザのような証明書リストが含まれていない。

CA証明書の注入でHTTPSブート完全実現

解決策は、システムの証明書バンドルをOVMF用フォーマットに変換することだった：

# システムバンドルをOVMF用フォーマットに変換
p11-kit extract --format=edk2-cacerts --filter=ca-anchors --overwrite cacerts.bin

この証明書バンドルをファームウェア設定として注入することで、HTTPSブートが正常に動作するようになった。

Le Bigot氏はまた、実際のハードウェア向けにvirt-fw-varsツールを使ったUEFI変数経由の設定方法も検証している：

# ファームウェアツールのインストール
sudo apt install python3-virt-firmware

# 新しい変数ストアに「Next Boot entry」を注入
virt-fw-vars --input /usr/share/OVMF/OVMF_VARS_4M.fd --set-boot-uri https://boot.netboot.xyz/ipxe/netboot.xyz-snponly.efi --output ./OVMF_VARS_4M.fd

まとめ：ネットワークブートの新時代

UEFI HTTP(S)ブートは、セキュリティと運用性の両面でPXEを大きく上回る。特に、TLS証明書による暗号化・認証により、インターネット経由でも安全なブートが実現できる。

本記事で紹介された実装は、一見単純な「HTTPからHTTPS」の変更の背後にある技術的複雑さと、それを段階的に解決するアプローチを示している。低レイヤー開発において、依存関係の特定とデバッグログの活用がいかに重要かも実感できるだろう。

詳細はIntroduction to UEFI HTTP(S) boot with Qemu/OVMFを参照していただきたい。