古いLinuxOS VM + セキュアブートについて

先日、セキュアブートを有効にした古いCentOSバージョンの仮想マシンインストールに失敗する事象に遭遇しました。

結論としてはセキュリティ対策上の仕様によるものだったのですが、備忘と共有のためここに記します。

インストール失敗の原因について
原因を少し考察
最後に

インストール失敗の原因について

以下、インストールを試行した環境情報です。

項目		設定値
ハイパーバイザー		ESXi8.0 U1a
OS		CentOS 8.4
仮想マシン互換性バージョン		20 (ESXi8.0)
起動オプション (仮想マシンの編集)	ファームウェア	EFI
	セキュアブート	ON (デフォルト)

失敗の原因となったのはOSと仮想マシンバージョンの組み合わせでした。

以下KBに記載の通り、仮想マシン互換性バージョン20では一部の古いLinuxOSでセキュアブートを有効にすると、インストールが失敗します。

kb.vmware.com

失敗時は、仮想マシンのログファイルであるvmware.logに、"SECUREBOOT: Image DENIED"と出力されます。

ー－－－－－－－－－－－－－－－－－－－－－－－－－－－

2023-07-19T04:56:24.605Z In(05) vcpu-0 - SECUREBOOT: Signature: 1 in db, 0 in dbx, 0 unrecognized, 0 unsupported alg.
2023-07-19T04:56:24.605Z In(05) vcpu-0 - SECUREBOOT: Hash: 0 in db, 1 in dbx.
2023-07-19T04:56:24.605Z In(05) vcpu-0 - SECUREBOOT: Image DENIED.

ー－－－－－－－－－－－－－－－－－－－－－－－－－－－

なお、互換性バージョンが19以下の場合はインストールが可能なので、[互換性バージョン19でOS導入後、ブートローダーを更新し、互換性バージョンを20にアップグレード]といった方法が解決策として示されています。(あるいはセキュアブートを無効に設定する方法も対処策となります)

原因を少し考察

当事象はGRUB2の脆弱性 (CVE-2020-10713) 対策の一環として、CentOSのブートローダーが拒否リスト(dbx)に該当し、起動を拒否されたことで発生します。

dbxはセキュアブートを構成するコンポーネントの一部で、不正なブートローダーの起動を無効にするために使用されます。

名称	説明
KEK (Key Exchange Key)	dbとdbxを編集するための鍵大抵、OSベンダー毎に異なるキーを所持
PK (Platform Key)	KEKを編集するための鍵大抵、ハードウェア製造元 (OEM) によって提供される
db (Authorized DB)	信頼された証明書およびハッシュ署名された efi バイナリとロード可能な rom を検証するために使用される
dbx (Unauthorized DB)	信頼されない証明書およびハッシュ efi バイナリとロード可能な rom を無効にするために使用される

セキュアブートの起動プロセスを見てみると、dbおよびdbxがOSの起動可否に関わっていることがわかります。

前述の通り、当事象の解決策として"互換性バージョン"19"以下でインストールを実施すること"が挙げられています。

では、互換性バージョン"20"と"19"の違いは何かという話になりますが、"20"からUEFIのバージョンが上がっており、それに平行する形でdbxの更新が行われているものと思われます。

ESXi Host	UEFI version
ESXi Host	VM Hardware version 20 or later	VM Hardware version 19 through 8
ESXi 8.0 or later	2.7	2.4
ESXi 7.0 U3	N/A	2.4
ESXi 7.0 U2 - 6.0	N/A	2.3.1
ESXi 5.5-5.0	N/A	2.3.0