11 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にどのように実装されているかを示すヒントです。
11.1 セキュアブート #
UEFIの世界では、ブートストラッププロセスの保護とは、信頼チェーンの確立を意味します。SUSE Linux Enterprise Serverとの関連では、「プラットフォーム」はこの信頼チェーンのルートであり、マザーボードおよびオンボードファームウェアが「プラットフォーム」とみなされます。別の言い方をすれば、ハードウェアベンダー、およびそのハードウェアベンダーからコンポーネントの製造元やOSベンダーなどにつながる信頼チェーンです。
信頼は公開鍵の暗号で表されます。ハードウェアベンダーは、ファームウェアにいわゆるプラットフォームキー(PK)を設定し、信頼のルートを表します。オペレーティングシステムベンダーなどとの信頼関係は、このプラットフォームキーを使ってキーに署名することによって文書化されます。
最後に、これらの「信頼された」キーのいずれかで署名されていない限りファームウェアがコード(OSブートローダも、PCI Expressカードやディスクのフラッシュメモリに保存されたドライバも、ファームウェアのアップデートも)を実行できないようにすることによって、セキュリティが確立されます。
セキュアブートを使用するには、ファームウェアによって信頼されたキーで署名されたOSローダが必要であり、読み込むカーネルが信頼できることを検証するためにOSローダが必要です。
キー交換キー(KEK)をUEFIキーデータベースに追加できます。この方法で、PKのプライベート部分で署名されている限り、他の証明書を使用できます。
11.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と呼びます。
次に、ブートローダはカーネルを検証および起動し、カーネルがモジュールで同じことを実行します。
11.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に複数のベンダーのキーを信頼させることができ、ブートローダからのデュアルブートやマルチブートが可能です。
11.1.3 カスタムカーネルのブート #
以下はhttp://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/"
証明書の作成の詳細については、http://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リストを起動します。証明書を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」を押して確認します。また、ファームウェアメニューに、署名データベースに新しいキーを追加する方法が用意されている場合があります。
11.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を参照してください。
11.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パラメータはカーネルに影響を及ぼしません。
11.2 その他の情報 #
http://www.uefi.org —UEFIのホームページです。現在のUEFI仕様が掲載されています。
Olaf Kirch氏およびVojtěch Pavlík氏によるブログ記事(上の章の内容はこれらの記事に基づいています)。
http://en.opensuse.org/openSUSE:UEFI —UEFIとopenSUSEに関するページです。