UEFI Secure Boot と MIRACLE LINUX をブートさせるまで

前置き

UEFI Secure Boot( もしくは縮めて Secure Boot) とは UEFI(Unified Extensible Firmware Interface) 仕様 2.3.1 ^※1 から定義された、ブート時の間に信頼された認証局によって署名されていないコードの起動をブロックするセキュリティ機能です。この機能では主に以下のようなソフトウェアが保護の対象となります。

ブートローダー
カーネル
カーネルモジュール
UEFI アプリケーション

Secure Boot によって実現されるセキュリティ上のメリット

近年 OS やアンチマルウェアのセキュリティ機能が強化され、悪意ある開発者が作成するマルウェアの機能が制限されるようになり、攻撃する対象として、OS がブートする前の低レイヤー環境を狙った物が増えつつあります ( こういったマルウェアは rootkits や bootkits として呼ばれます ) Secure Boot によって、OS( オペレーティングシステム ) が起動する前のブート前の段階にある環境のセキュリティが向上させ、攻撃を緩和させることができます。

一般論として、OS が起動する前に悪意あるコードが起動していた場合、OS 側の機能ではセキュリティや安全を確保することはできません、このようなケースではすでにマルウェアは動作しているからです。
つまり悪意あるコードが動作すること自体を UEFI 側からブロックする必要があります。

Secure Boot はコードに対して信頼された認証局によって署名されていることを求めることによって、このような起動をブロックすることができます。( 例えば意図的に署名されていないブートローダーを配置すると、'Security Violation' というメッセージを出して起動に至らないことを簡単に確認できます )

Secure Boot 機能の賛否

メリットのみに着目すると、Secure Boot はいいことづくめのように見えますが、課題もあります。それはハードウェアはどの認証局を信用すべきか、独立したベンダーは誰からどのように署名を貰うかという課題です。この記事では x86_64 環境に限定した事情を解説します。
市場に出回る x86_64 ハードウェアでは実質的にある一つのキーのみが共通キーとして登録されています、それは Windows のベンダーである Microsoft の証明書 (Microsoft's UEFI CA) です。^※2
また Windows Certificate による認証を受けるには Secure Boot 機能はデフォルトで enable である必要があります。
そのため、Windows 以外の OS は Secure Boot が広く普及した市場では、他に使用できる共通キーが無いためブート不能になる恐れがありました。^※3
対応策として、いくつかの方法が考えられました。ここでは Linux 向けの Secure Boot 対応に尽力した Matthew Garrett 氏のブログ記事 ^※4 の内容から実際には採用されなかった方法を紹介します。

ベンダーはリリースするバイナリに自身で署名し、対応する証明書をハードウェアベンダーに組み込んでもらう。
Linux ディストリビューション向けの共通キーを作り、ハードウェアベンダーに搭載してもらい、ルート鍵や証明書の配布、署名プロセスを特定団体が管理する。
ベンダーは自身のリリースするバイナリを個別に直接 Microsoft の署名サービスから署名を貰う。

上記のうち最初の 2 つの選択肢には以下のような問題があります、
前者にはまず、各ハードウェアベンダーに個別に証明書を搭載してもらうことは現実的ではないという問題があります、またこのアプローチを採用した場合、著名なベンダーは他のベンダーより優先的に証明書を搭載してもらいやすく、ベンダーロックインに繋がる可能性もあり、分断を招くかもしれません、そのため採用されませんでした。
後者の方法には鍵の管理に責任を持つ団体を見つける必要があり、そのような団体の起ち上げや継続には高額なコストがかかります。そのためこの方法も採用できません。

最終的に採用されたアプローチは 3 つ目の方法に対して、追加の仕組みが入った方法です。
具体的にはブートローダーのマルチレイヤー化とレビューボードによるブートローダーのレビュープロセスが入った方法です。レビュープロセスについては後ほど解説します。

ブートローダーのマルチレイヤー化と起動までのシークエンス

Linux をインストールした場合、組み合わせて使われるブートローダーといえば GRUB^※5 を連想される方が多いのではないでしょうか。Secure Boot が導入された UEFI 環境でも一般的な構成として GRUB が使われるのは変わりません ^※6、ただし署名を検証するための薄いレイヤーとして新しい別のブートローダーが導入されています。このブートローダーは 'shim' という名前で知られています。( この英単語に ' 楔 ' という意味があるため、ソフトウェアでしばしば何らかを媒介する薄いレイヤーという意味で使われ、同名のソフトウェアが多数存在しますが、この記事では UEFI 向けブートローダーとして開発された shim を指します https://github.com/rhboot/shim )

GRUB も同様にブートローダーとして動作します、ただし Secure Boot 機能に着目しない場合、通常 shim を意識する必要は無く GRUB を意識することの方が多いでしょう。

Secure Boot の理解のため、shim が導入されマルチレイヤー化した状態での起動シークエンスについて解説します。まずハードウェアに電源が入った後、起動した UEFI は First-stage ブートローダーである shim の署名を確認します、このとき shim には有効な署名がされている必要があります。^※7 署名が有効な場合、shim は起動され自身が内部に保持している証明書によって、Second-stage として動作する GRUB の署名を確認します、この処理では GRUB の署名と対応する証明書は Microsoft UEFI CA 等によって発行された証明書である必要はなく、ベンダー自身 ( 通常、shim や GRUB、Linux カーネルなどをビルドした個人・団体 ) が発行した証明書をチェックします。GRUB の有効性を確認したあと、shim は処理を引き渡し、GRUB は OS が起動する前の初期化処理やカーネルの署名を検証し、OS の起動処理に入ります。カーネルや init から先の処理については省略します。

shim が導入されマルチレイヤー化した状態での起動シークエンスについて

このブートの一連のシークエンスによりハードウェアを直接操作できる低レイヤーのコードはすべて有効な署名がされていること、UEFI またはすでに検証されており信頼できることが確認されているコードから、順繰りに起動されていることを強制できます。

ブートローダーに署名を貰うには

この一連の処理を実現するには各コンポーネントに有効な署名がされていること、そして First-stage ブートローダーである shim は、Microsoft キーによって署名されている必要があります。そのため Microsoft Windows Hardware Developer Program からベンダーが自身でビルドした shim バイナリへの署名を申請する必要があります。^※8
Microsoft から UEFI 向けに動作するファームウェアバイナリが署名を受けるための要件として UEFI Signing Requirements ^※9 というドキュメントがあります、このドキュメントには第 12 項に提出物が shim である場合の特記事項があり、shim のレビューボード [9] によって承認される必要があるということが書かれています。^※10
この一節が指しているのがブートローダーのレビュープロセスです、このレビューボードによって承認されない限り、Microsoft から署名をしてもらうことはできません。このレビューボードは Secure Boot 対応のため shim への署名を必要とするボランティアによって構成されており、お互いに申請をピアレビューする形式を取っています。^※11

MIRACLE LINUX をブートさせるまで、レビュープロセスの道

さて、このレビュープロセスですが独立ベンダーが Secure Boot に対応するに当たって最も苦労するのが、おそらくこのレビューを accept してもらうことでしょう。

Secure Boot 機能の賛否のところでも解説したように、特定のベンダーが特権的な地位を持つのは好ましくないため、基準を満たした申請は手際よく accept されるのが望ましいはずです。しかしながら 2022 年時点では、最終的に accpet を出す権限を持った限られた数のレビュワー ^※12 と前者を手伝う非公式なレビュワー、どちらも申請の数に対して数と実際のレビュー作業が足りていません、ボランティアワークであるためレビューを無理強いすることもできません。筆者自身も他ベンダーが出した申請のピアレビューし、基準に達していない・おかしい部分があれば指摘するなどの作業を行いましたが、レビュワー向けのきちんとしたガイドラインなどもあまり整っていないため、他ベンダーのレビューをするだけでなかなか骨の折れる作業でした。作業中に新しい脆弱性が発見され他の申請と一緒に機械的に一斉クローズされる、返信を貰うのに長い時間がかかり、その間に新しいバージョンがリリースされるなどの不可抗力的にやり直さなくてはいけない場面もあり、最初に調査を始めてから年単位の時間がかかりましたが、幸運にも MIRACLE LINUX 9 向けの申請が 2022 年の 8 月に accept されたため、MIRACLE LINUX 9 は Secure Boot に対応したディストリビューションとしてリリースすることができました。^※13

まとめ

本記事では Secure Boot と、現在の形に至った歴史的な経緯及び現在の状況について解説を行いました。Secure Boot やブートローダーの署名について日本語で書かれたドキュメントはあまり多くないため皆様のご参考になれば幸いです。

注釈

※1: https://uefi.org/press-release/UEFI_Forum_Releases_UEFI_2.3.1_Specification_Update_and_Schedules_July_3_2012
※2: Windows 8 以降、Microsoft は Windows Certificate を通して、証明書の登録を求めています。
※3: 当時の議論では Secure Boot は証明書をユーザーが追加できない場合、実質的にこれは Restricted Boot であるという批判などもありました。また一つのバイナリに対して複数の証明書に対応するような署名はできないという仕様上の制約も関係します
https://www.fsf.org/campaigns/campaigns/secure-boot-vs-restricted-boot
https://mjg59.dreamwidth.org/30420.html
※4: mjg59 | Implementing UEFI Secure Boot in Fedora https://mjg59.dreamwidth.org/12368.html
※5: 現代の GRUB のメジャーバージョンは 2 なので GRUB2, grub2 とも呼ばれます。
※6: もちろん例外はあり、GRUB を使わない構成も考えられます、その場合 shim は別のブートローダーを検証します。
※7: 有効性の検証としては、PK(Platform Key), MOK(Machine Owner Key) などの UEFI 変数に登録された証明書によって署名されていること、dbx 変数や shim 自身が管理する SBAT の revoke 処理により失効されていないことが確認される必要があります。Microsoft UEFI CA は PK に登録されています。
※8: このポータルは通常 Windows 向けのドライバへの署名などを申請するために用意されていますが、shim に関しては例外的に Windows とは直接関係ありませんがここから申請します。
※9: UPDATED: UEFI Signing Requirements https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916
※10: 以下当該ドキュメントからの引用 >
"If your submission is a SHIM (handing off execution to another bootloader), then you must first submit to the SHIM review board and be approved before a submission will be signed. This review board will check to ensure the following: "
※11: https://github.com/rhboot/shim-review/issues
MIRACLE LINUX 9 のレビューは https://github.com/rhboot/shim-review/issues/264 にて 2022 年 8 月 22 日に accepted されました。
※12: 2022 年時点では複数のベンダー (Red Hat, Debian, Canonical) からなる 3 人の限られたメンバーのみ確認しています。
※13: 実際にはその後、Microsoft Azure のポータルでも操作方法を調べたり、不可解なエラーにより申請の画面までたどり着けないなどのトラブルシューティングの作業があり、これもなかなか大変でした。