コンテンツコンテンツ
管理ガイド
  1. このガイドについて
  2. I サポートと共通タスク
    1. 1 YaSTオンラインアップデート
    2. 2 サポート用システム情報の収集
    3. 3 テキストモードのYaST
    4. 4 Snapperを使用したシステムの回復とスナップショット管理
    5. 5 VNCによるリモートアクセス
    6. 6 コマンドラインツールによるソフトウェアの管理
    7. 7 BashとBashスクリプト
  3. II システム
    1. 8 64ビットシステム環境での32ビットと64ビットのアプリケーション
    2. 9 Linuxシステムのブート
    3. 10 systemdデーモン
    4. 11 journalctl:systemdジャーナルのクエリ
    5. 12 ブートローダGRUB 2
    6. 13 UEFI (Unified Extensible Firmware Interface)
    7. 14 特別なシステム機能
    8. 15 プリンタの運用
    9. 16 udevによる動的カーネルデバイス管理
    10. 17 X Windowシステム
    11. 18 FUSEによるファイルシステムへのアクセス
  4. III サービス
    1. 19 ネットワークの基礎
    2. 20 SLP
    3. 21 NTPによる時刻の同期
    4. 22 ドメインネームシステム
    5. 23 DHCP
    6. 24 NetworkManagerの使用
    7. 25 Samba
    8. 26 NFS共有ファイルシステム
    9. 27 Autofsによるオンデマンドマウント
    10. 28 ファイルの同期
    11. 29 Apache HTTPサーバ
    12. 30 YaSTを使用したFTPサーバの設定
    13. 31 Squidプロキシサーバ
    14. 32 SFCBを使用したWebベースの企業管理
  5. IV モバイルコンピュータ
    1. 33 Linuxでのモバイルコンピューティング
    2. 34 電源管理
  6. V トラブルシューティング
    1. 35 ヘルプとドキュメント
    2. 36 最も頻繁に起こる問題およびその解決方法
  7. A マニュアルの更新
  8. B サンプルネットワーク
  9. C GNU Licenses
ナビゲーション
適用先 SUSE Linux Enterprise Server 12

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

13.1 セキュアブート

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

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

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

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

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

13.1.1 SUSE Linux Enterpriseへの実装

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

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

セキュアブート機能を使用するには、マスタブートレコード(MBR)を使用した古いパーティションをGUIDパーティションテーブル(GPT)に置換する必要があります。

YaSTは、インストール時にEFIモードを検出すると、GPTパーティションの作成を試みます。UEFIでは、FATフォーマットのEFIシステムパーティション(ESP)上でEFIプログラムが見つかるものと想定されます。

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

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

UEFIのセキュアブートプロセス
図 13.1 UEFIのセキュアブートプロセス

実装階層においてSUSEはshimローダを使用します。これは法的問題を回避するスマートなソリューションで、証明書および署名の手順が大幅に簡素化されます。shimローダの処理は、ELILOや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は、最初にFedoraによった開発されたshim (小さくシンプルなEFIブートローダ)で起動します。システム上のUEFIキーデータベースで利用可能なKEKにもとづいて、SUSE KEKで署名された証明書およびMicrosoft発行の証明書によって署名されます。

これによって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形式でキーと証明書をパッケージ化します。

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

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

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

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

    pesign -n . -S -i vmlinuz.signed

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

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

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

    sudo cp cert.der /boot/efi/
  9. 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」を押して確認します。

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

13.1.4 機能と制限

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

  • 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 その他の情報

このページを印刷