適用項目 SUSE Linux Enterprise Server 15 SP4

17 UEFI (Unified Extensible Firmware Interface) #

UEFI (Unified Extensible Firmware Interface) は、システムハードウェアに付属のファームウェア、システムのすべてのハードウェアコンポーネント、およびオペレーティングシステムの間のインタフェースです。

UEFIは、従来のPC-BIOSに代わって、PCで幅広く利用されるようになっています。たとえば、UEFIは64ビットシステムを適切にサポートし、最も重要な機能の1つである安全なブート(「セキュアブート」、ファームウェアバージョン2.3.1c以降が必要)を提供します。最後に、UEFIを使用すると、すべてのx86プラットフォームで標準のファームウェアが利用可能になります。

さらに、UEFIには以下の利点があります。

GUIDパーティションテーブル(GPT)を使う大きなディスク(2 TiB以上)からのブート。
CPUに依存しないアーキテクチャおよびドライバ。
ネットワーク機能を持つ柔軟なプレOS環境。
PC-BIOSライクなエミュレーション経由でレガシーオペレーティングシステムのブートをサポートするCSM(Compatibiity Support Module)。

詳細については、http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interfaceを参照してください。以降のセクションは、UEFIの一般的な概要を示すものではなく、特定の機能がSUSE Linux Enterprise Serverにどのように実装されているかを示すヒントです。

17.1 セキュアブート #

UEFIの世界では、ブートストラッププロセスの保護とは、信頼チェーンの確立を意味します。SUSE Linux Enterprise Serverとの関連では、「プラットフォーム」はこの信頼チェーンのルートであり、マザーボードおよびオンボードファームウェアが「プラットフォーム」とみなされます。別の言い方をすれば、ハードウェアベンダー、およびそのハードウェアベンダーからコンポーネントの製造元やOSベンダーなどにつながる信頼チェーンです。

信頼は公開鍵の暗号で表されます。ハードウェアベンダーは、ファームウェアにいわゆるプラットフォームキー(PK)を設定し、信頼のルートを表します。オペレーティングシステムベンダーなどとの信頼関係は、このプラットフォームキーを使ってキーに署名することによって文書化されます。

最後に、これらの「信頼された」キーのいずれかで署名されていない限りファームウェアがコード(OSブートローダも、PCI Expressカードやディスクのフラッシュメモリに保存されたドライバも、ファームウェアのアップデートも)を実行できないようにすることによって、セキュリティが確立されます。

セキュアブートを使用するには、ファームウェアによって信頼されたキーで署名されたOSローダが必要であり、読み込むカーネルが信頼できることを検証するためにOSローダが必要です。

キー交換キー(KEK)をUEFIキーデータベースに追加できます。この方法で、PKのプライベート部分で署名されている限り、他の証明書を使用できます。

17.1.1 SUSE Linux Enterprise Serverへの実装 #

Microsoftのキー交換キー(KEK)がデフォルトでインストールされます。

注記: GUIDパーティションテーブル(GPT)が必要

セキュアブート機能は、UEFI/x86_64インストール環境ではデフォルトで有効になっています。Enable Secure Boot Support(セキュアブートサポートの有効化)オプションは、ブートローダの設定ダイアログのBoot Code Options(ブートコードオプション)タブにあります。ファームウェアでセキュアブートが有効になっている場合のブート、および無効になっている場合のブートもサポートします。

図 17.1: セキュアブートサポート #

セキュアブート機能を使用するには、マスタブートレコード(MBR)を使用した古いパーティションをGUIDパーティションテーブル(GPT)に置換する必要があります。YaSTは、インストール時にEFIモードを検出すると、GPTパーティションの作成を試みます。UEFIでは、FATフォーマットのEFIシステムパーティション(ESP)上でEFIプログラムが見つかるものと想定されます。

UEFIセキュアブートに対応するには、ブートローダがデジタル署名されており、ファームウェアがそのデジタル署名を信頼されたキーとして認識することが必要です。このキーはファームウェアによってあらかじめ信頼されているので、手動での操作は不要です。

これには2つの方法があります。1つは、ハードウェアベンダーにSUSEキーを署名してもらい、SUSEがその署名を使ってブートローダに署名する方法です。もう1つは、MicrosoftのWindows Logo Certificationプログラムを利用してブートローダの認定を受け、MicrosoftにSUSE署名キーを認識してもらう(つまり、MicrosoftのKEKを使って署名してもらう)方法です。これで、SUSEは、UEFI署名サービス(この場合はMicrosoft)によって署名されたローダを入手できます。

図 17.2: UEFIのセキュアブートプロセス #

実装層で、SUSEは、デフォルトでインストールされているshimローダを使用します。法的な問題を回避するスマートなソリューションであり、証明書と署名に関する手順を大きく簡素化します。shimローダの処理は、GRUB 2などのブートローダをロードすることです。次にこのブートローダが、SUSEキーのみで署名されたカーネルをロードします。SUSEは、UEFIセキュアブートが有効化されたSLE11 SP3の新規インストールで、この機能を提供します。

信頼ユーザには2種類あります。

1つ目は、キーを保持するユーザです。プラットフォームキー(PK)によって、ほとんどすべてのことが許可されます。キー交換キー(KEK)では、PKの変更を除き、PKに可能なすべてのことが許可されます。
2つ目は、マシンに物理的にアクセスできる任意のユーザです。物理的にアクセスできるユーザは、マシンを再起動したりUEFIを設定したりできます。

UEFIには、これらのユーザのニーズを満たすため、2種類の変数があります。

1つ目はいわゆる「認証された変数」で、ブートプロセス(いわゆるブートサービス環境)と実行中のOSの両方からアップデートできます。これは、変数の新しい値が、その変数の古い値が署名されたときと同じキーで署名されている場合にのみ実行できます。また、この変数は、より大きなシリアル番号を持つ値にのみ追加または変更できます。
2つ目は、「ブートサービス専用変数」と呼ばれるものです。この変数は、ブートプロセス中に動作する任意のコードにアクセスできます。ブートプロセスの終了後、OSが起動する前に、ブートローダはExitBootServicesコールを呼び出す必要があります。その後、これらの変数にはアクセスできなくなり、OSはこれらに触れられません。

さまざまなUEFIキーリストは1つ目のタイプなので、オンラインでの更新、追加、および、キー/ドライバ/ファームウェアの指紋のブラックリスト登録ができます。セキュアブートの実装に役立つのは、2つ目の「Boot Service Only Variable (ブートサービス専用変数)」です。これは、安全かつオープンソースで使いやすくなっており、GPL v3と互換性があるためです。

SUSEはshim (SUSEとMicrosoftが署名した小型でシンプルなEFIブートローダ)から始まります。

これによってshimのロードおよび実行が可能になります。

shimは、続いて、ロードしようとしているブートローダが信頼されていることを確認します。デフォルトで、shimは、本体に組み込まれている独自のSUSE証明書を使用します。また、shimは、追加のキーを「登録」してデフォルトのSUSEキーを上書きできます。以下、これらを「マシン所有者キー」、または省略してMOKと呼びます。

次に、ブートローダはカーネルを検証および起動し、カーネルがモジュールで同じことを実行します。

17.1.2 Machine Owner Key(マシン所有者キー、MOK) #

ブートプロセスの一部である特定のカーネル、ドライバ、または他のコンポーネントを置き換えるには、マシン所有者キー(MOK)を使用する必要があります。mokutilツールはMOKを管理するのに役立ちます。

mokutilを使用してMOK登録要求を作成できます。要求は、MokNewと呼ばれるUEFIランタイム(RT)変数に保存されます。次のブート時に、shimブートローダはMokNewを検出し、MokManagerをロードします。これにより、いくつかのオプションが表示されます。Enroll key from disk (ディスクからキーを登録)およびEnroll hash from disk (ディスクからハッシュを登録)オプションを使用して、MoListにキーを追加することができます。Enroll MOK (MOKを登録)オプションを使用して、MokNew変数からキーをコピーします。

ディスクからのキーの登録は通常、シムがgrub2のロードに失敗し、MokManagerのロードにフォールバックしたときに行われます。MokNewはまだ存在しないため、UEFIパーティションでキーを検索するオプションがあります。

17.1.3 カスタムカーネルのブート #

以下はhttps://en.opensuse.org/openSUSE:UEFI#Booting_a_custom_kernelにもとづいています。

セキュアブートでは、セルフコンパイルカーネルを使用できます。ただし、独自の証明書を使って署名し、その証明書をファームウェアまたはMOKに知らせる必要があります。

カスタムのX.509キー、および署名に使用される証明書を作成します。
```
openssl req -new -x509 -newkey rsa:2048 -keyout key.asc \
  -out cert.pem -nodes -days 666 -subj "/CN=$USER/"
```
証明書の作成の詳細については、https://en.opensuse.org/openSUSE:UEFI_Image_File_Sign_Tools#Create_Your_Own_Certificateを参照してください。

PKCS#12形式でキーと証明書をパッケージ化します。

> openssl pkcs12 -export -inkey key.asc -in cert.pem \
  -name kernel_cert -out cert.p12

pesignとともに使用するNSSデータベースを生成します。
```
> certutil -d . -N
```
PKCS#12に含まれるキーおよび証明書をNSSデータベースにインポートします。
```
> pk12util -d . -i cert.p12
```
pesignを使用して、新しい署名でカーネルを「bless」します。
```
> pesign -n . -c kernel_cert -i arch/x86/boot/bzImage \
  -o vmlinuz.signed -s
```
カーネルイメージの署名をリスト表示します。
```
> pesign -n . -S -i vmlinuz.signed
```
その時点で、通常通り/bootにカーネルをインストールできます。カーネルにはカスタム署名があるため、署名に使用された証明書をUEFIファームウェアまたはMOKにインポートする必要があります。
ファームウェアまたはMOKにインポートするため、証明書をDERフォーマットに変換します。
```
> openssl x509 -in cert.pem -outform der -out cert.der
```
よりアクセスしやすくするため、証明書をESPにコピーします。
```
> sudo cp cert.der /boot/efi/
```
mokutilを使用して自動的にMOKリストを起動します。
- 1. 証明書をMOKにインポートします。
```
> mokutil --root-pw --import cert.der
```
    --root-pwオプションにより、rootユーザを直接使用できます。
  2. これから登録する証明書のリストを確認します。
```
> mokutil --list-new
```
  3. システムを再起動します。shimによってMokManagerが起動されるはずです。rootパスワードを入力して、MOKリストに証明書をインポートすることを確認してください。
  4. 新しくインポートしたキーが登録されたかどうかを確認します。
```
> mokutil --list-enrolled
```
- 1. また、MOKを手動で起動する場合は以下の手順を実行します。
    再起動
  2. GRUB 2メニューでcキーを押します。
  3. タイプ:
```
chainloader $efibootdir/MokManager.efi
boot
```
  4. Enroll key from diskを選択します。
  5. cert.derファイルに移動して<Enter>キーを押します。
  6. 指示に従ってキーを登録します。通常、「0」を押してから「y」を押して確認します。
    また、ファームウェアメニューに、署名データベースに新しいキーを追加する方法が用意されている場合があります。

17.1.4 Inbox以外のドライバの使用 #

セキュアブートを有効にしたインストールでは、Inbox以外のドライバ(SUSE Linux Enterprise Serverに付属していないドライバ)の追加がサポートされません。SolidDriver/PLDPで使用される署名キーは、デフォルトでは信頼されていません。

セキュアブートを有効にしたインストールでは、サードパーティドライバを2つの方法でインストールできます。いずれの方法でも以下を行います。

インストール前にファームウェア/システム管理ツールを使用して、必要なキーをファームウェアデータベースに追加します。このオプションは、使用している特定のハードウェアによって異なります。詳細については、ハードウェアベンダーに問い合わせてください。
https://drivers.suse.com/またはハードウェアベンダーから入手したブート可能なドライバISOを使用して、初回ブート時に必要なキーをMOKリストに登録します。

ブート可能なドライバISOを使用してドライバキーをMOKリストに登録するには、次の手順に従います。

空のCD/DVDメディアに上記のISOイメージを書き込みます。
この新しいCD/DVDメディアを使用してインストールを開始します。その際には、標準のインストールメディア、またはネットワークインストールサーバへのURLを用意しておきます。
ネットワークインストールを行う場合、ブートコマンドラインでinstall=オプションを使用して、ネットワークインストールソースのURLを入力します。
光学メディアからインストールする場合、インストーラが最初にドライバキットからブートされた後、製品の最初のインストールディスクを挿入するように要求されます。
アップデートされたドライバを含むinitrdが、インストールに使用されます。

詳細については、https://drivers.suse.com/doc/Usage/Secure_Boot_Certificate.htmlを参照してください。

17.1.5 機能と制限 #

セキュアブートモードでブートする場合、次の機能が適用されます。

UEFIのデフォルトのブートローダがある場所へのインストール。これは、EFIブートエントリを維持または復元するメカニズムです。
UEFIを介して再起動する。
フォールバック先のレガシーBIOSがない場合、XenハイバーバイザはUEFIを使用してブートする。
UEFI IPv6 PXEブートのサポート。
UEFIビデオモードのサポート。カーネルはUEFIからビデオモードを取得して、同じパラメータでKMSモードを設定できます。
USBデバイスからのUEFIブートがサポートされる。

セキュアブートモードでブートする場合、次の制限が適用されます。

セキュアブートを簡単に回避できないようにするため、セキュアブートで実行する場合は一部のカーネル機能が無効になっています。
ブートローダ、カーネル、およびカーネルモジュールが署名されている必要があります。
KexecおよびKdumpは無効になっています。
ハイバネーション(ディスクの休止)は無効になっています。
ルートユーザであっても、/dev/kmemおよび/dev/memにアクセスできません。
ルートユーザであっても、I/Oポートにアクセスできません。すべてのX11グラフィカルドライバはカーネルドライバを使用する必要があります。
sysfs経由でPCI BARにアクセスすることはできません。
ACPIのcustom_methodは使用できません。
asus-vmiモジュールに対してdebufgsを使用できません。
acpi_rsdpパラメータはカーネルに影響を及ぼしません。

17.2 詳細情報 #

https://www.uefi.org —UEFIのホームページです。現在のUEFI仕様が掲載されています。
Olaf Kirch氏およびVojtěch Pavlík氏によるブログ記事(上の章の内容はこれらの記事に基づいています)。
https://en.opensuse.org/openSUSE:UEFI —UEFIとopenSUSEに関するページです。