UEFI Secure Boot と Linux の微妙な関係

新しい PC を物色するなかで、Linux が起動できるのか気になるので、UEFI Secure Boot について調べている。
セキュリティでよくある、安全性と利便性のトレードオフの話ではあるのだけど、今回は場合によっては Linux が全く起動しなくなるので話が重い。
まだ勉強中だけど、調べたことを順次まとめていく。

• 仕様
  • http://www.uefi.org/specs/
  • http://www.uefi.org/learning_center/

• 実装
  • Insyde H2O
    • http://www.insydesw.com/products
  • AMI Aptio
    • http://www.ami.com/Products/BIOSandEFIFirmware/Aptio/
  • Phoenix SecureCore? Tiano
    • http://www.phoenix.com/pages/phoenix-securecore-tiano-tm

UEFI Secure Boot は Windows 8 世代の PC から搭載されている機能。

http://windows.microsoft.com/ja-JP/windows-8/system-requirements

セキュア ブートには、UEFI v2.3.1 Errata B をサポートし、UEFI 署名データベースに Microsoft Windows 証明機関が含まれているファームウェアが必要です

この機能が有効になっていると、PC で Windows 8 以外の OS (Windows XP や Linux など) が起動できないのだが、
"Designed for Windows 8" シールが貼ってある PC では工場出荷状態で有効になっている機能なので、
このままだと今後の PC では Linux が標準で起動できなくなるという、恐ろしい話。

https://sysdev.microsoft.com/ja-JP/Hardware/LPL/
http://download.microsoft.com/download/A/D/F/ADF5BEDE-C0FB-4CC0-A3E1-B38093F50BA1/windows8-hardware-cert-requirements-system.pdf

System.Fundamentals.Firmware.UEFISecureBoot
Target Feature: System.Fundamentals.Firmware
Title: All client systems must support UEFI Secure boot
Applicable OS Versions
・Windows 8 (x86)
・Windows 8 (x64)
・Windows RT
・Windows Server 2012
Description
Note: These requirements are "If Implemented" for Server systems and apply only if a Server system supports UEFI Secure Boot.
1. Mandatory. For the purposes of UEFI Secure Boot, the platform shall expose an interface to Secure Boot, whereby the system firmware is compliant with the following sections and sub-sections of UEFI version 2.3.1 Errata B:
a. 7.1
b. 7.2
c. 7.2.1
d. 27.2
e. 27.5 - 27.8 (as further profiled below).
2. Mandatory. Secure Boot must ship enabled Configure UEFI Version 2.3.1 Errata B variables SecureBoot=1 and SetupMode=0 with a signature database (EFI_IMAGE_SECURITY_DATABASE) necessary to boot the machine securely pre-provisioned, and include a PK that is set and a valid KEK database. The system uses this database to verify that only trusted code (for example: trusted signed boot loader) is initialized, and that any unsigned image or an image that is signed by an unauthorized publisher does not execute. The contents of the signature database is determined by the OEM, based on the required native and third-party UEFI drivers, respective recovery needs, and the OS Boot Loader installed on the machine. The following Microsoft-provided EFI_CERT_X509 signature shall be included in the signature database: "CN=Microsoft Windows Production PCA 2011" and "Cert Hash(sha1): 58 0a 6f 4c c4 e4 b6 69 b9 eb dc 1b 2b 3e 08 7b 80 d0 67 8d" which shall use the following SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}, must also be included in the form of either an EFI_CERT_X509_GUID or EFI_CERT_RSA2048_GUID type.
Note: Must NOT contain the following certificate: "CN=Microsoft Windows PCA 2010" and "Cert Hash(sha1): c0 13 86 a9 07 49 64 04 f2 76 c3 c1 85 3a bf 4a 52 74 af 88"
Note II: Windows Server systems may ship with Secure Boot disabled, but all other provisions of this sub-requirement must be met

とはいえ、この機能は UEFI の設定で無効にできる (PC メーカーの実装次第) ので、今後の PC で Linux が全く使えなくなるというわけでもない。
http://blogs.msdn.com/b/b8/archive/2011/09/22/protecting-the-pre-os-environment-with-uefi.aspx

Who is in control?

At the end of the day, the customer is in control of their PC. Microsoft’s philosophy is to provide customers with the best experience first, and allow them to make decisions themselves. We work with our OEM ecosystem to provide customers with this flexibility. The security that UEFI has to offer with secure boot means that most customers will have their systems protected against boot loader attacks. For the enthusiast who wants to run older operating systems, the option is there to allow you to make that decision.

http://blog.canonical.com/2011/10/28/white-paper-secure-boot-impact-on-linux/

we recommend that PCs include a User Interface to easily enable or disable Secure Boot and allow the user to chose to change their operating system.

だけど、Secure Boot を無効にすると、今度は Windows 8 が起動できなくなるケースがあるらしい (僕が実機で確かめた範囲ではそのようなことは無かったので、情報あれば教えてください)。

つまり、(上記の情報が正しいなら) Windows 8 と Linux のデュアルブートをするには、Linux でも出荷状態の Secure Boot に対応する必要があることになる。
(デュアルブートにしなくても、仮想化で動かせばいいじゃん、という話は脇に置いておく)

(ひょっとすると、Windows 8 が起動しなくなるというのは、鍵を変更した場合の話なのかもしれない。)

http://mjg59.dreamwidth.org/12368.html

A system in custom mode should allow you to delete all existing keys and replace them with your own. After that it's just a matter of re-signing the Fedora bootloader (like I said, we'll be providing tools and documentation for that) and you'll have a computer that will boot Fedora but which will refuse to boot any Microsoft code.

Secure Boot への対応は The Linux Foundation, Ubuntu, RedHat/Fedora, SUSE 等が各々の方法で進めているようだけど、どれもまだ進行中のもよう。

The Linux Foundation はマイクロソフトの署名サービスを使って pre-bootloader を署名してもらっている。
pre-bootloader で UEFI Secure Boot をパスした後、通常の bootloader で起動しよう、というアプローチらしい。
この試みがうまくいけば、サイトで pre-bootloader を公開してもらえるので、全ての Linux ディストリビューションに恩恵がありそう。

http://www.linuxfoundation.org/news-media/blogs/browse/2012/10/linux-foundation-uefi-secure-boot-system-open-source

The process of obtaining a Microsoft signature will take a while, but once it is complete, the pre-bootloader will be placed on the Linux Foundation website for anyone to download and make use of.

http://www.linuxfoundation.jp/content/jp_linux-foundation-uefi-secure-boot-system-open-source

Microsoft の署名を取得するまで少し時間がかかりますが、それさえ完了すれば、プリブートローダーは The Linux Foundation の Web サイトに置かれ、だれでもダウンロードして使うことができます。

だけど、マイクロソフトの手続き待ちで進んでいないみたい。

http://www.zdnet.com/linux-foundation-uefi-secure-boot-key-for-windows-8-pcs-delays-explained-7000007841/

We’re still waiting for Microsoft to give the Linux Foundation a validly signed pre-bootloader.

Ubuntu はマイクロソフトではなく Canonical の鍵を使ってブートローダーに署名していく方針。
PC メーカー (OEM/ODM) に鍵の搭載を働きかけていて、Ubuntu プリインストールな PC では Secure Boot が使えるようになるということらしい。

http://blog.canonical.com/2012/06/22/an-update-on-ubuntu-and-secure-boot/

Canonical has generated an Ubuntu key, and we are in active discussions with partners to implement simple ways for enterprises and consumers to use this key. These conversations have not concluded, and as a result we cannot detail the plans of our OEM partners yet.

ただし、インストール CD では、やはりマイクロソフトの鍵を使うとのこと。

https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035445.html

Booting our CDs will rely on a loader image signed by Microsoft's
WinQual key, for much the same reasons as Fedora: it's a key that,
realistically, more or less every off-the-shelf system is going to have,
as it also signs things like option ROMs, and the UEFI specification
only allows an image to be signed by a single key.

RedHat/Fedora の中の人の考えでも、マイクロソフトに署名してもらうのが現実的だという結論。

http://mjg59.dreamwidth.org/12368.html

The last option wasn't hugely attractive, but is probably the least worst. Microsoft will be offering signing services through their sysdev portal. It's not entirely free (there's a one-off $99 fee to gain access edit: The $99 goes to Verisign, not Microsoft - further edit: once paid you can sign as many binaries as you want), but it's cheaper than any realistic alternative would have been. It ensures compatibility with as wide a range of hardware as possible and it avoids Fedora having any special privileges over other Linux distributions. If there are better options then we haven't found them. So, in all probability, this is the approach we'll take. Our first stage bootloader will be signed with a Microsoft key.

http://www.zdnet.com/blog/open-source/linus-torvalds-on-windows-8-uefi-and-fedora/11187

What Fedora ended up doing was using Microsoft's secure boot key signing services through their sysdev portal for one-off $99 fee.

Debian 陣営は DebConf 12 の時点では何も決まらず、来年の Wheezy までには決めようということらしい。

http://www.phoronix.com/scan.php?page=news_item&px=MTEzNjU

While this work was discussed, nothing genuinely new was brought up during the 45-minute discussion. It's still not decided what approach Debian will ultimately support whether it's like Fedora using GRUB2 and singing the entire stack, Ubuntu using efilinux and only signing the low-level bits, or some entirely new approach for handling EFI/SecureBoot. However, something has to be decided for Debian 7.0 "Wheezy" seeing as when it ships early next year there will be a number of motherboards and PCs shipping with this headache-inducing technology.

それぞれ色々な動きはあるのだけど、まだ活動中で決定版的なアプローチは決まっていない。

Linux なので、複数のアプローチが共存していくことになるとは思うが、
さすがに、PC メーカーが Canonical などの Linux 用の鍵を全ての PC に搭載するモチベーションは低いはず。
(Dell が Ubuntu モデルを出したりしているので、一部 PC には搭載されるかもしれない)

実質的に、今後の全ての PC に搭載されるのはマイクロソフトの鍵だけなので、
Secure Boot が有効な PC に対応するためには、
どこかでマイクロソフトの署名が必要となるのが現実かな。

マイクロソフトの署名サービス (有償) を使って自分のモジュールに署名してもらうことができるかもしれないけど、
The Linux Foundation が待たされているようなので、個人で手続きしてスムーズに進むとは思えない。
(The Linux Foundation だから待たされているという可能性もあるので、やってみる価値はあるかもしれない)

http://sysdev.microsoft.com/
http://msdn.microsoft.com/en-us/library/windows/hardware/gg463091.aspx

というわけで、まだまだ調査中。

SUSE の MOK を使う考え方や、shim についても、そのうちまとめてみる。
http://mjg59.dreamwidth.org/17542.html
http://mjg59.dreamwidth.org/20303.html
https://www.suse.com/blogs/uefi-secure-boot-details/