目次にジャンプページナビゲーションにジャンプ: 前のページ[アクセスキーp]/次のページ[アクセスキーn]
documentation.suse.com / SUSE Linux Enterprise Serverマニュアル / 管理ガイド / Linuxシステムのブート / UEFI (Unified Extensible Firmware Interface)
適用項目 SUSE Linux Enterprise Server 15 SP2

13 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にどのように実装されているかを示すヒントです。

13.1 セキュアブート

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

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

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

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

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

13.1.1 SUSE Linux Enterprise Serverへの実装

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

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

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

セキュアブートサポート
図 13.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)によって署名されたローダを入手できます。

UEFIのセキュアブートプロセス
図 13.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と呼びます。

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

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

ユーザ(マシンの所有者)がブートプロセスの任意のコンポーネントを置換する場合は、Machine Owner Key(マシン所有者キー、MOK)を使用します。mokutilsツールがコンポーネントの署名およびMOKの管理を支援します。

登録プロセスでは、まずマシンを起動し、shimのロード中に(キーを押すなどして)ブートプロセスを中断します。これによってshimが登録モードに移行するので、ユーザは、デフォルトのSUSEキーをブートパーティションのファイルに含まれるキーに置換できます。ユーザがこの処理を選択すると、shimはそのファイルのハッシュを計算し、結果をBoot Service Only(ブートサービス専用)変数にします。これによってshimは、ブートサービス以外でファイルが変更された場合にその変更を検出でき、ユーザ承認済みのMOKリストの改ざんを回避できます。

これらすべてがブート時に行われ、検証済みのコードのみが実行されます。このため、コンソールにいるユーザのみがマシン所有者のキーセットを使用できます。OSにリモートアクセスするマルウェアやハッカーではあり得ません。ハッカーやマルウェアはファイルの変更しかできず、Boot Service Only(ブートサービス専用)変数に保存されたハッシュを変更できないためです。

いったんロードされshimによって検証されたブートローダは、カーネルを検証する場合はshimにコールバックします(検証コードの複製を避けるため)。shimはMOKと同じリストを使用し、カーネルをロードできるかどうかをブートローダに知らせます。

このようにして、独自のカーネルまたはブートローダをインストールできます。物理的にそこにいることによって新しいキーセットをインストールしそれを認証する必要があるのは、最初の再起動時のみです。MOKは単一のMOKではなくリストなので、shimに複数のベンダーのキーを信頼させることができ、ブートローダからのデュアルブートやマルチブートが可能です。

13.1.3 カスタムカーネルのブート

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

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

  1. カスタムのX.509キー、および署名に使用される証明書を作成します。

    openssl req -new -x509 -newkey rsa:2048 -keyout key.asc \
      -out cert.pem -nodes -days 666 -subj "/CN=$USER/"

    証明書の作成の詳細については、http://en.opensuse.org/openSUSE:UEFI_Image_File_Sign_Tools#Create_Your_Own_Certificateを参照してください。

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

    tux > openssl pkcs12 -export -inkey key.asc -in cert.pem \
      -name kernel_cert -out cert.p12
  3. pesignとともに使用するNSSデータベースを生成します。

    tux > certutil -d . -N
  4. PKCS#12に含まれるキーおよび証明書をNSSデータベースにインポートします。

    tux > pk12util -d . -i cert.p12
  5. pesignを使用して、新しい署名でカーネルをblessします。

    tux > pesign -n . -c kernel_cert -i arch/x86/boot/bzImage \
      -o vmlinuz.signed -s
  6. カーネルイメージの署名をリスト表示します。

    tux > pesign -n . -S -i vmlinuz.signed

    その時点で、通常通り/bootにカーネルをインストールできます。カーネルにはカスタム署名があるため、署名に使用された証明書をUEFIファームウェアまたはMOKにインポートする必要があります。

  7. ファームウェアまたはMOKにインポートするため、証明書をDERフォーマットに変換します。

    tux > openssl x509 -in cert.pem -outform der -out cert.der
  8. よりアクセスしやすくするため、証明書をESPにコピーします。

    tux > sudo cp cert.der /boot/efi/
  9. mokutilを使用して自動的にMOKリストを起動します。

      1. 証明書をMOKにインポートします。

        tux > mokutil --root-pw --import cert.der

        --root-pwオプションにより、rootユーザを直接使用できます。

      2. これから登録する証明書のリストを確認します。

        tux > mokutil --list-new
      3. システムを再起動します。shimによってMokManagerが起動されるはずです。rootパスワードを入力して、MOKリストに証明書をインポートすることを確認してください。

      4. 新しくインポートしたキーが登録されたかどうかを確認します。

        tux > 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」を押して確認します。

        また、ファームウェアメニューに、署名データベースに新しいキーを追加する方法が用意されている場合があります。

13.1.4 Inbox以外のドライバの使用

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

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

  • インストール前にファームウェア/システム管理ツールを使用して、必要なキーをファームウェアデータベースに追加します。このオプションは、使用している特定のハードウェアによって異なります。詳細については、ハードウェアベンダーに問い合わせてください。

  • https://drivers.suse.com/またはハードウェアベンダーから入手したブート可能なドライバISOを使用して、初回ブート時に必要なキーをMOKリストに登録します。

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

  1. 空のCD/DVDメディアに上記のISOイメージを書き込みます。

  2. この新しいCD/DVDメディアを使用してインストールを開始します。その際には、標準のインストールメディア、またはネットワークインストールサーバへのURLを用意しておきます。

    ネットワークインストールを行う場合、ブートコマンドラインでinstall=オプションを使用して、ネットワークインストールソースのURLを入力します。

    光学メディアからインストールする場合、インストーラが最初にドライバキットからブートされた後、製品の最初のインストールディスクを挿入するように要求されます。

  3. アップデートされたドライバを含むinitrdが、インストールに使用されます。

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

13.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パラメータはカーネルに影響を及ぼしません。

13.2 その他の情報