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)がデフォルトでインストールされます。
セキュアブート機能は、UEFI/x86_64インストール環境ではデフォルトで有効になっています。オプションは、ダイアログのタブにあります。ファームウェアでセキュアブートが有効になっている場合のブート、および無効になっている場合のブートもサポートします。
セキュアブート機能を使用するには、マスタブートレコード(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)によって署名されたローダを入手できます。
    実装層で、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をロードします。これにより、いくつかのオプションが表示されます。およびオプションを使用して、MoListにキーを追加することができます。オプションを使用して、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にコピーします。 - >- sudocp cert.der /boot/efi/
- mokutilを使用して自動的にMOKリストを起動します。- 証明書をMOKにインポートします。 - >mokutil --root-pw --import cert.der- --root-pwオプションにより、- rootユーザを直接使用できます。
- これから登録する証明書のリストを確認します。 - >mokutil --list-new
- システムを再起動します。 - shimによってMokManagerが起動されるはずです。- rootパスワードを入力して、MOKリストに証明書をインポートすることを確認してください。
- 新しくインポートしたキーが登録されたかどうかを確認します。 - >mokutil --list-enrolled
 
- また、MOKを手動で起動する場合は以下の手順を実行します。 - 再起動 
- GRUB 2メニューで - cキーを押します。
- タイプ: - chainloader $efibootdir/MokManager.efi boot 
- を選択します。 
- cert.derファイルに移動して<Enter>キーを押します。
- 指示に従ってキーを登録します。通常、「 - 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に関するページです。 

