ArchWiki - 利用者の投稿記録 [ja]

GRUB

2026-08-09T08:18:58Z

ELC: ELC (トーク) による版 41687 を取り消し

[[Category:ブートローダー]]
[[Category:GNU]]
[[de:GRUB]]
[[en:GRUB]]
[[es:GRUB]]
[[pl:GRUB]]
[[pt:GRUB]]
[[ru:GRUB]]
[[zh-hans:GRUB]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Master Boot Record}}
{{Related|GUID Partition Table}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|GRUB Legacy}}
{{Related|GRUB/EFI サンプル}}
{{Related|GRUB/ヒントとテクニック}}
{{Related|マルチブート USB ドライブ}}
{{Related articles end}}
[https://www.gnu.org/software/grub/ GRUB] (GRand Unified Bootloader) は[[ブートローダー]]です。現在の GRUB は '''GRUB 2''' とも呼ばれています。元の GRUB ([[GRUB Legacy]]) はバージョン 0.9x に対応しています。このページでは GRUB 2 についてのみ説明します。

{{Note|この記事全体で、{{ic|''esp''}} は [[EFI システムパーティション]] (別名 ESP) のマウントポイントを表します。}}

== サポートされているファイルシステム ==

GRUB には[https://www.gnu.org/software/grub/manual/grub/html_node/Features.html#Features 複数のファイルシステム] (特に重要なものとしては [[FAT32]]、[[ext4]]、[[Btrfs]]、[[XFS]]) に対する独自のサポートがあります。注意事項に関しては [[#サポートのないファイルシステム]] 章を見てください。

{{Warning|ファイルシステムには、GRUB がまだ対応していない新しい機能が導入されることがあります。その場合、GRUB と互換性の無い機能を無効化しない限り、そのファイルシステムを {{ic|/boot}} に対して使用するべきではありません。この問題は、[[パーティショニング#/boot|/boot パーティション]]を別に分けて、[[FAT32]] などの広くサポートされているファイルシステムを使用することで、回避することができます。}}

== UEFI システム ==

{{Note|
* 次のページを読んで理解しておくことをおすすめします: [[Unified Extensible Firmware Interface]]、[[パーティショニング#GUID Partition Table]]、[[Arch ブートプロセス#UEFI_2]]。
* UEFI を使うようにインストールする場合、Arch のインストールメディアを UEFI モードで起動することが重要です。さもないと、''efibootmgr'' が GRUB の UEFI ブートエントリを追加できません。[[#デフォルト/フォールバックのブートパス|フォールバックブートパス]]へのインストールは NVRAM を使用しないため、BIOS モードでも可能です。
* UEFI を使用してディスクから起動するには EFI システムパーティションが必要です。[[EFI システムパーティション#既存のパーティションの確認]] に従って、すでに EFI システムパーティションが存在するかどうかを確認してください。存在しない場合は作成する必要があります。
* この記事全体で、{{ic|insmod}} を使って追加の GRUB2 モジュールを挿入可能であると仮定しています。[[#Shim-lock]] で議論されているように、これはセキュアブートが有効化されている UEFI システムには当てはまりません。セキュアブートシステム上で標準の GRUB EFI ファイル {{ic|grubx64.efi}} に含まれていない追加の GRUB モジュールを使用したい場合は、{{ic|grub-mkstandalone}} を使って追加の GRUB モジュールを含めた GRUB EFI {{ic|grubx64.efi}} を再生成しなければなりません。
}}

=== インストール ===

{{Note|
* UEFI の実装はマザーボード製造者ごとに異なっています。以下で説明されている手順は広い範囲の UEFI システムで動作するように意図されています。しかし、この方法を適用しているにも関わらず問題が発生する場合は、あなたのハードウェア固有のケースにおける詳細な情報を (可能であれば解決策も) 共有することが推奨されます。そのようなケースのために [[GRUB/EFI サンプル]] の記事が提供されています。
* このセクションでは、あなたが x64 (64 ビット) UEFI のシステムに対して GRUB をインストールしようとしていると仮定します。IA32 (32 ビット) UEFI の場合は (32 ビット CPU と混同しないでください)、適切な場所で {{ic|x86_64-efi}} を {{ic|i386-efi}} に置き換えてください。[[Unified Extensible Firmware Interface#UEFI ファームウェアのビット数を調べる]] の手順を見て、UEFI のビット数を調べてください。
}}

まず、{{Pkg|grub}} と {{Pkg|efibootmgr}} を[[インストール]]してください。''GRUB'' はブートローダである一方、''efibootmgr'' はブートエントリを NVRAM に書き込むために GRUB のインストールスクリプトによって使用されます。

そして、以下の手順に従って GRUB をディスクにインストールしてください:

# [[EFI システムパーティション#パーティションのマウント|EFI システムパーティションをマウント]]してください。そして、このセクションの後の部分で出てくる {{ic|''esp''}} という記述をそのマウントポイントに置き換えてください。
# ブートローダの識別子を選んでください、ここでは仮に {{ic|GRUB}} としましょう。{{ic|''esp''/EFI/}} にあなたが選んだものと同じ名前のディレクトリが作成され、そこに EFI バイナリが格納されます。その名前が UEFI ブートメニューの GRUB ブートエントリの名前になります。
# 以下のコマンドを実行して、GRUB EFI アプリケーション {{ic|grubx64.efi}} を {{ic|''esp''/EFI/GRUB/}} に、モジュールを {{ic|/boot/grub/x86_64-efi/}} にインストールしてください。
::{{Note|
::* GRUB をブートローダとしてインストールするシステム内でパッケージをインストールし、{{ic|grub-install}} を実行してください。つまり、ライブインストール環境から起動している場合、{{ic|grub-install}} は (インストール先の) chroot 環境の中で実行する必要があるということです。何らかの理由で、インストールされたシステムの外で {{ic|grub-install}} を実行する必要がある場合、マウントした {{ic|/boot}} ディレクトリへのパスを {{ic|1=--boot-directory=}} オプションに渡してください。例: {{ic|1=--boot-directory=/mnt/boot}}
::* 一部のマザーボードは、空白を含む {{ic|bootloader-id}} を扱うことができません。}}
::{{bc|1=# grub-install --target=x86_64-efi --efi-directory=''esp'' --bootloader-id=GRUB}}

上記のインストール作業が完了した後、メインの GRUB ディレクトリが {{ic|/boot/grub/}} に作成されています。別の場所を指定する方法については [[GRUB/ヒントとテクニック#代替インストール方法]] を見てください。{{ic|grub-install}} は[[#ファームウェアブートマネージャーに GRUB エントリを作成する|ファームウェアのブートマネージャにもエントリを作成]]しようとすることに注意してください。その名前は上記の例では {{ic|GRUB}} となります。しかし、ブートエントリが埋まっていると、これは失敗します。この場合は [[efibootmgr]] を使って必要ないエントリを削除してください。

設定を確定したあとに[[#メイン設定ファイルの生成|メインの設定ファイルを生成]]することを忘れないでください。

{{Tip|{{ic|--removable}} オプションを使うと、GRUB は {{ic|''esp''/EFI/BOOT/BOOTX64.EFI}} にインストールされます ({{ic|i386-efi}} ターゲットの場合は {{ic|''esp''/EFI/BOOT/BOOTIA32.EFI}})。その結果、EFI 変数がリセットされた場合やドライブを他のコンピュータに移した場合でもそのドライブから起動することができるようになります。通常は BIOS を使用する方法と同じようにドライブを選択することで使うことができます。Windows とデュアルブートする場合、Windows は通常そこに EFI 実行ファイルを配置するので注意してください。とはいえ、そのファイルは Windows の UEFI ブートエントリを再生成するためだけに使用されます。[[Mac]] 上に GRUB をインストールする場合、このオプションを使用する必要があります。一部のデスクトップマザーボード (特に MSI のマザーボード) はここに保存されている EFI 実行ファイルしか見ないので、このオプションが必須になります。
UEFI アップデートを実行すると、既存の UEFI ブートエントリが削除されるかもしれません。なので、"removable" なブートエントリを有効化しておくと、それをフォールバックとして利用できます。}}

{{Note|
* {{ic|--efi-directory}} と {{ic|--bootloader-id}} は GRUB UEFI 専用です。{{ic|--efi-directory}} は、非推奨となった {{ic|--root-directory}} を置き換えます。
* {{ic|grub-install}} コマンドに ''device_path'' オプション (例えば {{ic|/dev/sda}}) が無いことに気付いたかもしれません。実際、''device_path'' は GRUB EFI インストールスクリプトによって無視されます。UEFI ブートローダーは MBR ブートコードもパーティションブートセクタも全く使用しないのです。
}}

問題が発生した場合は [[#UEFI|UEFI のトラブルシューティング]] を見て下さい。加えて [[GRUB/ヒントとテクニック#UEFI の詳細情報]] も参照してください。

=== セキュアブートサポート ===

GRUB は、CA 鍵か shim のいずれかを使用するセキュアブートを完全にサポートしています。しかし、インストールのコマンドは、どちらを使用するかによって異なります。

{{Warning|
* [[セキュアブート]]を不適切に設定すると、システムが起動不能になる可能性があります。セキュアブートを有効化した後に何らかの理由により起動できなくなった場合、ファームウェアでセキュアブートを無効化し、システムを再起動する必要があります。
* ブートローダで不必要なモジュールをロードすると、セキュリティリスクを発生させる可能性があります。これらのコマンドは、必要なときにだけ使用してください。
}}

==== CA 鍵 ====

CA 鍵を使うには、インストールのコマンドは次のようになります:

# grub-install --target=x86_64-efi --efi-directory=''esp'' --bootloader-id=GRUB --modules="tpm" --disable-shim-lock

==== Shim-lock ====

{{Note|このセクションに進む前に、[[セキュアブート#shim]] に書かれてある指示の通りにし、{{pkg|sbsigntools}} をセットアップして鍵を受け取る準備を整えておく必要があります。}}

Shim-lock を使用する場合、GRUB をセキュアブートモードでブートさせるには、[[vmlinuz]] と [[initramfs]] のイメージが含まれているファイルシステムを読むために必要なモジュール全てが GRUB のバイナリに含まれていなければなりません。

GRUB バージョン {{ic|2.06.r261.g2f4430cc0}} から、セキュアブートモードで {{ic|insmod}} を使ってモジュールをロードすることは許可されなくなりました (任意のコードをサイドロードできてしまう可能性があるからです)。GRUB モジュールが EFI バイナリ内に組み込まれていない場合、GRUB はそれらのモジュールをサイドロード/{{ic|insmod}} しようと試み、その結果、以下のようなメッセージにより GRUB の起動が失敗します:

error: prohibited by secure boot policy

[https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian/build-efi-images?h=debian/2.06-2ubuntu12 Ubuntu の公式ビルドスクリプト]によると、Ubuntu では以下の GRUB モジュールが署名済み GRUB EFI バイナリ {{ic|grubx64.efi}} に組み込まれています:

* [https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian/build-efi-images?h=debian/2.06-2ubuntu12#n87 "基本" モジュール]。CD や簡単にパーティショニングされたディスクからブートするために必要: {{ic|all_video}}、{{ic|boot}}、{{ic|btrfs}}、{{ic|cat}}、{{ic|chain}}、{{ic|configfile}}、{{ic|echo}}、{{ic|efifwsetup}}、{{ic|efinet}}、{{ic|ext2}}、{{ic|fat}}、{{ic|font}}、{{ic|gettext}}、{{ic|gfxmenu}}、{{ic|gfxterm}}、{{ic|gfxterm_background}}、{{ic|gzio}}、{{ic|halt}}、{{ic|help}}、{{ic|hfsplus}}、{{ic|iso9660}}、{{ic|jpeg}}、{{ic|keystatus}}、{{ic|loadenv}}、{{ic|loopback}}、{{ic|linux}}、{{ic|ls}}、{{ic|lsefi}}、{{ic|lsefimmap}}、{{ic|lsefisystab}}、{{ic|lssal}}、{{ic|memdisk}}、{{ic|minicmd}}、{{ic|normal}}、{{ic|ntfs}}、{{ic|part_apple}}、{{ic|part_msdos}}、{{ic|part_gpt}}、{{ic|password_pbkdf2}}、{{ic|png}}、{{ic|probe}}、{{ic|reboot}}、{{ic|regexp}}、{{ic|search}}、{{ic|search_fs_uuid}}、{{ic|search_fs_file}}、{{ic|search_label}}、{{ic|sleep}}、{{ic|smbios}}、{{ic|squash4}}、{{ic|test}}、{{ic|true}}、{{ic|video}}、{{ic|xfs}}、{{ic|zfs}}、{{ic|zfscrypt}}、{{ic|zfsinfo}}
* x84_64-efi アーキテクチャ用の [https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian/build-efi-images?h=debian/2.06-2ubuntu12#n147 "プラットフォーム固有" のモジュール]。例えば:
** {{ic|play}}: ブート中に音を鳴らす
** {{ic|cpuid}}: ブート時に CPU の機能を確認する
** {{ic|tpm}}: Measured Boot / [[TPM|Trusted Platform Modules]] をサポートする
* [https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian/build-efi-images?h=debian/2.06-2ubuntu12#n159 "高度な" モジュール]。以下が含まれます:
** {{ic|cryptodisk}}: [[dm-crypt|plain モードで暗号化された]]ディスクからブートする
** {{ic|gcry_''アルゴリズム''}}: 特定のハッシュアルゴリズムと暗号化アルゴリズムをサポートする
** {{ic|luks}}: [[LUKS]] で暗号化されたディスクからブートする
** {{ic|lvm}}: [[LVM]] 論理ボリュームディスクからブートする
** {{ic|mdraid09}}、{{ic|mdraid1x}}、{{ic|raid5rec}}、{{ic|raid6rec}}: [[RAID]] 仮想ディスクからブートする

GRUB モジュールのリストはシェル変数の形にしなければなりません (ここでは {{ic|GRUB_MODULES}} と表記しています)。[https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian/build-efi-images 最新の Ubuntu スクリプト]をベースとして使い、あなたのシステムでは不要なモジュールを取り除くという方法を取ることもできます。モジュールを減らすと、ブートプロセスが比較的速くなり、ESP のスペースをいくらか節約できます。

また、セキュリティを高めるために、EFI バイナリに[https://github.com/rhboot/shim/blob/main/SBAT.md Secure Boot Advanced Targeting (SBAT)] ファイル/セクションを含める必要があります (GRUB が UEFI shim ローダから起動される場合)。SBAT ファイル/セクションには、GRUB バイナリに関するメタデータ (バージョン、メンテナ、開発者、上流の URL) が含まれており、特定の GRUB バージョンに脆弱性がある場合、shim がそのバージョンの GRUB のロードをブロックすることが容易になります [https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/#additional][https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2SecureBootBypass2021] (shim の [https://github.com/rhboot/shim/blob/main/SBAT.md UEFI shim bootloader secure boot life-cycle improvements] というドキュメントで説明されています)。

SBAT セクションが {{ic|grubx64.efi}} に無いと、shim は {{ic|grubx64.efi}} の起動に失敗します。

GRUB がインストールされている場合、シンプルな SBAT ''.csv'' ファイルが {{ic|/usr/share/grub/sbat.csv}} で提供されています。

その {{ic|/usr/share/grub/sbat.csv}} ファイルと必要な {{ic|GRUB_MODULES}} を使って GRUB を再インストールし、GRUB バイナリを署名してください:

# grub-install --target=x86_64-efi --efi-directory=''esp'' --modules="${GRUB_MODULES}" --sbat /usr/share/grub/sbat.csv
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/GRUB/grubx64.efi ''esp''/EFI/GRUB/grubx64.efi
# cp ''esp''/EFI/GRUB/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi

再起動し、''MokManager'' で鍵を選択すれば、セキュアブートが機能するはずです。

==== セキュアブートを使用する ====

インストール後は、[[セキュアブート#セキュアブートを実現する]] を見て、セキュアブートを有効化する手順を確認してください。

CA 鍵の方法を取っている場合、鍵の管理や登録、ファイルの署名は {{pkg|sbctl}} で自動化できます。詳細は [[セキュアブート#sbctl でより簡単に行う]] を見てください。

== BIOS システム ==

=== GUID Partition Table (GPT) 特有の手順 ===

BIOS/[[GPT]] の構成では、[https://www.gnu.org/software/grub/manual/grub/html_node/BIOS-installation.html#BIOS-installation BIOS ブートパーティション]が必要です。GRUB は {{ic|core.img}} をこのパーティションに埋め込みます。

{{Note|
* この方法を試す前に、すべてのシステムでこのパーティショニング方式がサポートされているわけではないということを心に留めておいてください。詳細は [[パーティショニング#GUID Partition Table]] を見てください。
* BIOS ブートパーティションは BIOS/GPT のセットアップでのみ GRUB が必要とします。BIOS/MBR セットアップでは、GRUB は MBR の後にある隙間を {{ic|core.img}} のために使用します。しかし、GPT では最初のパーティションの前に未使用の領域があることは保証されていません。
* [[UEFI]] システムでは、ブートセクタが組み込まれないので、BIOS ブートパーティションは必要ありません。しかし、UEFI システムでは依然として [[EFI システムパーティション]]が必要です。
}}

ディスク上にパーティションタイプ GUID {{ic|21686148-6449-6E6F-744E-656564454649}} の、ファイルシステムの無い 1 メビバイト (''fdisk'' や ''gdisk'' で {{ic|1=+1M}}) のパーティションを作成してください。

* [[fdisk]] では、パーティションタイプ {{ic|BIOS boot}} を選択してください。
* [[gdisk]] では、パーティションタイプコード {{ic|ef02}} を選択してください。
* [[parted]] では、そのパーティションで {{ic|bios_grub}} フラグをセット/アクティブ化してください。

このパーティションはどのような順番で配置しても良いですが、ディスクの先頭 2 TiB 以内になければなりません。このパーティションは GRUB のインストール前に作成する必要があります。パーティションの準備が完了したら、以下の指示に従ってブートローダーをインストールします。

GPT のアライメント仕様から外れますが、最初のパーティションの前にあるスペースは BIOS ブートパーティションとしても使用できます。このパーティションは定期的にアクセスされるものではないのでパフォーマンスの問題は無視できますが、一部のディスクユーティリティは警告を発します。''fdisk'' や ''gdisk'' では、セクター 34 から 2047 までの区間の新しいパーティションを作成して、先のパーティションタイプを設定してください。見える状態のパーティションが先頭から始まるようにするには、このパーティションを最後に追加することを検討してください。

=== Master Boot Record (MBR) 特有の手順 ===

通常、MBR でパーティションされた環境において [[MBR]] の後の隙間 (512 バイトの MBR 領域の後ろで最初のパーティションの前) は 31 KiB になっていて、このパーティションテーブルでは DOS 互換のシリンダーアライメントは問題になりません。しかしながら GRUB の {{ic|core.img}} 用に十分な領域を確保するために 1 から 2 MiB ほど MBR の後の領域をとることを推奨します ({{bug|24103}})。この領域を獲得したり他の 512 バイトでないセクターの問題を起こさないために ({{ic|core.img}} の埋め込みとは関係ありません) 1 MiB [[パーティショニング#パーティションアライメント|パーティションアライメント]]をサポートしているパーティションツールを使うのが得策です。

=== インストール ===

{{Pkg|grub}} パッケージを[[インストール]]してください ({{AUR|grub-legacy}} がインストールされている場合は置き換えられます。) 次に以下を実行してください:

# grub-install --target=i386-pc ''/dev/sdX''

{{ic|i386-pc}} は実際のアーキテクチャに関わらず使用されます。{{ic|''/dev/sdX''}} は GRUB がインストールされる '''ディスク''' ('''パーティションではありません''') です。例えば、{{ic|/dev/sda}}、{{ic|/dev/nvme0n1}}、{{ic|/dev/mmcblk0}} です。ブロックデバイスの命名方法については [[デバイスファイル#ブロックデバイスの名前]] を参照してください。

次に、[[#メイン設定ファイルの生成|メイン設定ファイルを生成]]する必要があります。

{{ic|/boot}} に [[LVM]] を使用している場合、GRUB を複数の物理ディスク上にインストールすることができます。

{{Tip|USB メモリなどに GRUB をインストールする他の方法については [[GRUB/ヒントとテクニック#代替インストール方法]] を参照してください。}}

{{ic|grub-install}} コマンドの詳細については、{{man|8|grub-install}} および [https://www.gnu.org/software/grub/manual/grub/html_node/BIOS-installation.html#BIOS-installation GRUB Manual] を参照してください。

== 設定 ==

インストールされたシステムでは、GRUB は起動の度に設定ファイル {{ic|/boot/grub/grub.cfg}} をロードします。ツールを使う場合は、[[#grub.cfg の生成]] を、手動で作成する場合は [[#grub.cfg のカスタマイズ]] を参照してください。

=== grub.cfg の生成 ===

このセクションでは {{ic|/etc/default/grub}} 設定ファイルの編集についてだけ扱っています。他のオプションは [[GRUB/ヒントとテクニック]] を見て下さい。

{{Note|{{ic|/etc/grub.d/}} 下のファイルや {{ic|/etc/default/grub}} に変更を加えた後は必ず[[#メイン設定ファイルの生成|メイン設定ファイルの再生成]]を行なって下さい。}}

{{Warning|GRUB の新しいバージョンで設定ファイルの構文が変更された場合、ブートローダーをアップデート/再インストールしてください ([[#UEFI システム]] や [[#BIOS システム]] を見てください)。設定が一致しないと、システムが起動できなくなる可能性があります。例えば、新しい設定では既存の GRUB バイナリが認識しない関数が使用されているかもしれず、想定外の動作を引き起こす可能性があります。}}

==== メイン設定ファイルの生成 ====

インストールした後は、メインの設定ファイル {{ic|/boot/grub/grub.cfg}} を生成する必要があります。生成プロセスは、{{ic|/etc/default/grub}} 内の様々なオプションや {{ic|/etc/grub.d/}} 下のスクリプトによって制御されます。{{ic|/etc/default/grub}} におけるオプションのリストと、それぞれのオプションの簡潔な説明は、GNU の[https://www.gnu.org/software/grub/manual/grub/html_node/Simple-configuration.html ドキュメント]を参照してください。

追加の設定をしていない場合、設定ファイル自動生成スクリプトは、ブートさせるシステムのルートファイルシステムを判定し、その情報を設定ファイルに保存します。これを成功させるには、システムを起動させているか、またはシステムに chroot していることが重要です。

{{Note|1=<nowiki></nowiki>
* デフォルトのファイルパスは {{ic|/boot/grub/grub.cfg}} です、{{ic|/boot/grub/i386-pc/grub.cfg}} ではありません。
* [[chroot]] や [[systemd-nspawn]] コンテナで ''grub-mkconfig'' を実行しようとした場合、次のようなエラーによりうまく行かないことがあります: {{ic|grub-probe: error: failed to get canonical path of ''/dev/sdaX''}}。この場合、[https://bbs.archlinux.org/viewtopic.php?pid=1225067#p1225067 このフォーラムの投稿]で記述されているように [[arch-chroot]] を使ってみて下さい。
}}

''grub-mkconfig'' ツールを使って {{ic|/boot/grub/grub.cfg}} を生成してください:

# grub-mkconfig -o /boot/grub/grub.cfg

デフォルトで、生成スクリプトは Arch Linux の[[カーネル]]のメニューエントリを自動的に設定に追加します。

{{Tip|
* [[カーネル]]をインストール/アンインストールした後は、上記の ''grub-mkconfig'' コマンドを再度実行する必要があります。
* 複数の GRUB エントリを管理するためのヒントとして、例えば {{Pkg|linux}} と {{Pkg|linux-lts}} の両方を使用している場合、[[GRUB/ヒントとテクニック#複数のエントリ]] を見てください。
}}

他のオペレーティングシステムのエントリを自動的に追加する方法は [[#他の OS の検出]] を見てください。

{{ic|/etc/grub.d/40_custom}} を編集して {{ic|/boot/grub/grub.cfg}} を再生成することで、追加のカスタムメニューエントリを追加することができます。または、{{ic|/boot/grub/custom.cfg}} を作成して、そこにカスタムのメニューエントリを追加することもできます。{{ic|/boot/grub/custom.cfg}} を編集した後に ''grub-mkconfig'' を再度実行する必要はありません。{{ic|/etc/grub.d/41_custom}} は必要な {{ic|source}} 文を設定ファイルに追加するからです。

{{Tip|{{ic|/etc/grub.d/40_custom}} は {{ic|/etc/grub.d/''nn''_custom}} を作成する際のテンプレートとして使うことができます。{{ic|''nn''}} の部分は優先順位で、スクリプトを実行する順番を決定します。スクリプトを実行する順番は GRUB ブートメニューエントリの配置を決定します。必要なスクリプトを確実に実行させるために、{{ic|''nn''}} は {{ic|06}} よりも大きくする必要があります。}}

カスタムのメニューエントリの例は [[#ブートメニューエントリの例]] を見てください。

==== 他の OS の検出 ====

''grub-mkconfig'' で、インストールされている他のシステムを検索して自動的にメニューに追加するには、 {{Pkg|os-prober}} パッケージを [[インストール]] して、他のシステムが起動するパーティションを[[マウント]]してください。その後、''grub-mkconfig'' を再実行します。もし、{{ic|Warning: os-prober will not be executed to detect other bootable partitions}} と出力されたら、{{ic|/etc/default/grub}} を編集して次の行を追加/アンコメントしてください:

GRUB_DISABLE_OS_PROBER=false

その後、もう一度試してください。

{{Note|
* 正確なマウントポイントは重要ではありません。''os-prober'' は {{ic|mtab}} を読み込んで、起動可能なエントリを検索すべき場所を特定します。
* 他のオペレーティングシステムをエントリに含めるために、''grub-mkconfig'' を実行するたびに対象のパーティションをマウントすることを忘れないでください。
* ''os-prober'' は、chroot 内で実行すると正しく動作しないかもしれません。そのような場合は、再起動してシステムに入り、再び試してください。
}}

{{Tip|最後に選択したブートエントリを GRUB に記憶させたい場合もあるでしょう、[[GRUB/ヒントとテクニック#以前のエントリを思い出させる]] を参照してください。}}

===== Windows =====

UEFI モードでインストールされた Windows の場合、Windows Boot Manager ({{ic|bootmgfw.efi}}) を含んでいる [[EFI システムパーティション]]がマウントされていることを確認してください。root として {{ic|os-prober}} を実行すると、Windows のエントリを検出・生成します。

BIOS モードでインストールされた Windows の場合、Windows ''システムパーティション'' をマウントしてください (そのパーティションの[[永続的なブロックデバイスの命名#by-label|ファイルシステムラベル]]は {{ic|System Reserved}} ({{ic|システムで予約済み}}) か {{ic|SYSTEM}} であるはずです)。root として {{ic|os-prober}} を実行すると、Windows のエントリを検出・生成します。

{{Note|BIOS モードでインストールされた Windows の場合:
* NTFS パーティションはデフォルトの Linux ドライバでマウントすると、必ずしも検出されないかもしれません。GRUB が検出しない場合、[[NTFS-3G]] をインストールして再マウントしてみてください。
{{Out of date| Windows 7 以降、{{ic|bootmgr}} は[[Wikipedia:System partition and boot partition#Microsoft definition|システムパーティション]]内にあり、このパーティションは暗号化されていません。}}
* 暗号化された Windows パーティションは、マウントする前に暗号化を解除する必要があるかもしれません。BitLocker では、[[cryptsetup]] や {{AUR|dislocker}} で実行できます。これで {{Pkg|os-prober}} が正しいエントリを追加できるはずです。
}}

==== 追加引数 ====

カスタムの追加引数を Linux イメージに渡すために、{{ic|/etc/default/grub}} で {{ic|GRUB_CMDLINE_LINUX}} と {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} 変数を設定することができます。これら2つは互いに追加され、標準のブートエントリを作成する際にカーネルに渡されます。''recovery'' ブートエントリについては、{{ic|GRUB_CMDLINE_LINUX}} だけが生成時に使われます。

両方を使う必要はありませんが、上手く使えば便利です。例えば、{{ic|1=GRUB_CMDLINE_LINUX_DEFAULT="resume=UUID=''uuid-of-swap-partition'' quiet"}} ({{ic|''uuid-of-swap-partition''}} は [[ハイバネート]]後に復帰できるようにするためのスワップパーティションの [[UUID]])。この例の設定では、(ハイバネートからの) 復帰をせず、メニューエントリからの起動中にカーネルメッセージを非表示にする {{ic|quiet}} も無いリカバリブートエントリを生成します。しかし、他の (標準の) メニューエントリはこれらのオプションを持ちます。

デフォルトでは、''grub-mkconfig'' はルートファイルシステムの [[UUID]] を検出して、設定にそれを反映します。これを無効化するには、{{ic|1=GRUB_DISABLE_LINUX_UUID=true}} をアンコメントしてください。

GRUB リカバリエントリを生成するには、{{ic|/etc/default/grub}} 内の {{ic|GRUB_DISABLE_RECOVERY}} が {{ic|true}} に設定されていない必要があります。

詳細は [[カーネルパラメータ]] を参照してください。

==== トップレベルのメニューエントリを設定する ====

デフォルトでは、''grub-mkconfig'' は、含まれているカーネルを {{ic|sort -V}} を使ってソートし、それらの中の最初のカーネルをトップレベルのエントリとして使用します。すなわち、例えば {{ic|/boot/vmlinuz-linux-lts}} は {{ic|/boot/vmlinuz-linux}} より前に来るので、{{Pkg|linux-lts}} と {{Pkg|linux}} の両方がインストールされている場合、LTS カーネルがトップレベルのメニューエントリとなります。これは、望ましくない場合があるでしょう。この挙動は、{{ic|/etc/default/grub}} 内の {{ic|1=GRUB_TOP_LEVEL=''path_to_kernel''"}} を指定することでオーバーライドすることができます。例えば、標準のカーネルをトップレベルのメニューエントリにするには、{{ic|1=GRUB_TOP_LEVEL="/boot/vmlinuz-linux"}} を使用します。

==== LVM ====

{{Warning|GRUB はシンプロビジョニングされた論理ボリュームをサポートしていません。}}

{{ic|/boot}} や {{ic|/}} に [[LVM]] を使用している場合、{{ic|lvm}} モジュールをプリロードするようにしてください:

{{hc|/etc/default/grub|2=
GRUB_PRELOAD_MODULES="... lvm"
}}

==== RAID ====

GRUB は [[RAID]] ボリュームの便利な管理手段を提供します。ボリュームをネイティブに管理できるようにするために、GRUB モジュール {{ic|mdraid09}} か {{ic|mdraid1x}} をロードする必要があります:

{{hc|/etc/default/grub|2=
GRUB_PRELOAD_MODULES="... mdraid09 mdraid1x"
}}

例えば、{{ic|/dev/md0}} は以下のようになります:

set root=(md/0)

パーティショニングされた RAID ボリューム (例: {{ic|/dev/md0p1}}) は以下のようになります:

set root=(md/0,1)

{{ic|/boot}} パーティションに RAID1 を使用している場合 (あるいは、{{ic|/boot}} が RAID1 ルートパーティション上に存在する場合) に GRUB をインストールするには、BIOS システム上では、両方のドライブ上で ''grub-install'' を実行してください。例:

# grub-install --target=i386-pc --debug /dev/sda
# grub-install --target=i386-pc --debug /dev/sdb

ここでは、{{ic|/boot}} が存在する RAID1 アレイが、{{ic|/dev/sda}} と {{ic|/dev/sdb}} に存在するとしています。

{{Note|GRUB は [[Btrfs]] RAID 0/1/10 からの起動をサポートしていますが、RAID 5/6 はサポートしていません。RAID 5/6 に対しては [[mdadm]] を使用することができます (mdadm は GRUB によってサポートされています)。

==== 暗号化された /boot ====

GRUB には暗号化された {{ic|/boot}} を起動するための特別なサポートがあります。これは、[[LUKS]] ブロックデバイスをアンロックして、GRUB の設定を読み込み、[[initramfs]] と [[カーネル]] をそのブロックデバイスからロードすることにより行われます。このオプションは[[dm-crypt/特記事項#暗号化されていない boot パーティションのセキュア化|暗号化されていないブートパーティション]]の問題を解決することを試みます。

{{Tip|{{ic|/boot}} を別のパーティションに保存する必要は'''ありません'''。システムのルート {{ic|/}} ディレクトリツリー下に保存することもできます。}}

{{Warning|GRUB 2.12rc1 の LUKS2 に対するサポートは限られています。詳細は [[#LUKS2]] セクションを見てください。}}

この機能を有効化するには、{{ic|/boot}} が存在するパーティションを通常通り [[LUKS]] を使って暗号化してください。そして、以下のオプションを {{ic|/etc/default/grub}} に追加してください。

{{hc|/etc/default/grub|output=
GRUB_ENABLE_CRYPTODISK=y
}}

このオプションは grub-install により使用され、grub の {{ic|core.img}} を生成します。

このオプションを追加した後やパーティションを暗号化した後に [[#インストール|GRUB を(再)インストール]]することを忘れないでください。

これだけだと、パスフレーズを2回入力させられることになります。1回目は起動の初期段階で GRUB が {{ic|/boot}} マウントポイントをアンロックするためのもので、2回目は iniramfs により実装されている root ファイルシステムそれ自体をアンロックするためのものです。[[dm-crypt/デバイスの暗号化#キーファイルを initramfs に埋め込む|キーファイル]]を使えば、これを防げます。

{{Warning|
* [[#メイン設定ファイルの生成|メインの設定ファイルを生成]]したいときは、{{ic|/boot}} がマウントされていることを確認してください。
* {{ic|/boot}} マウントポイントが関与するシステムアップデートを行うために、アップデートする前に、暗号化された {{ic|/boot}} がアンロックされていて、かつ、マウントされていることを確認してください。{{ic|/boot}} パーティションが別にある場合、[[crypttab]] を[[dm-crypt/デバイスの暗号化#キーファイルを initramfs に埋め込む|キーファイル]]と一緒に使うことでこれを自動化できます。
}}

{{Note|
* 特殊なキーマップを使用している場合、デフォルトの GRUB 環境にはそのようなキーマップが存在しません。このことは、[[LUKS]] ブロックデバイスをアンロックするためにどのようにしてパスフレーズを入力するかに関連しています。[[GRUB/ヒントとテクニック#初期ブートにおけるコアイメージの手動設定]] を参照してください。
* パスワードの入力画面が表示されない問題が発生した場合 (cryptouuid や cryptodisk、"device not found" に関係するエラー)、{{ic|1=--modules="part_gpt part_msdos"}} を {{ic|grub-install}} コマンドの最後に付け加えて GRUB を再インストールしてみてください。
}}

{{Tip|1=[https://bbs.archlinux.org/viewtopic.php?id=234607 pacman フック] を使用すれば、{{ic|/boot}} 内のファイルにアクセスする必要のあるアップグレード時に {{ic|/boot}} を自動マウントできます。}}

===== LUKS2 =====
{{Out of date|1=Grub 2.14rc1はArgon2iとArgon2id PBKDFsをサポートします。 [https://cgit.git.savannah.gnu.org/cgit/grub.git/commit/?id=6052fc2cf684dffa507a9d81f9f8b4cbe170e6b6 アップストリームのコミットを参照。]|2=:en:Talk:GRUB#grub_2:2.14rc1_added_support_for_LUKS2_+_argon2_encryption.}}

[[#インストール]] 章で説明されているように、{{ic|grub-install}} を使用して LUKS サポートありでブータブルな GRUB イメージを作成してください。ただし、いくつかの注意点があります:

* LUKS2 の初期サポートが GRUB 2.06 で追加されましたが、いくつかの制限があります。これらの制限は、GRUB 2.12rc1 で部分的にのみ対処されています。[https://savannah.gnu.org/bugs/?55093 GRUB bug #55093] を参照してください。
* GRUB 2.12rc1 から、{{ic|grub-install}} で LUKS2 のロックを解除するためのコアイメージを作成できるようになりました。しかし、PBKDF2 のみがサポートされており、Argon2 はサポートされていません。
* Argon2id (''cryptsetup'' デフォルト) と Argon2i PBKDF はサポートされていません ([https://savannah.gnu.org/bugs/?59409 GRUB bug #59409])。PBKDF2 のみのサポートです。

:{{Tip|LUKS2 と Argon のサポートパッチが施された {{AUR|grub-improved-luks2-git}} を使用できます。このパッケージの Argon サポートには UEFI システムが必要であることに注意してください。[https://aur.archlinux.org/packages/grub-improved-luks2-git#comment-911119]}}

{{Note|GRUB 2.12rc1 より前では、カスタムの GRUB 設定ファイルを使って {{ic|grub-mkimage}} コマンドで EFI バイナリを手動で作成する必要がありました。(例えば、{{ic|/boot/grub/grub-pre.cfg}} に {{ic|cryptomount}}、{{ic|insmod normal}}、そして {{ic|normal}} への呼び出しを追加する必要がありました。) しかし、これはもはや必要なくなり、{{ic|grub-install}} だけで十分です。ただし、2.06 からアップグレードした後に少なくとも一回は {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} を実行する必要があります。}}

起動中に無効なパスフレーズを入力して GRUB のレスキューシェルに入った場合、{{ic|cryptomount -a}} を実行してすべての (できれば1つだけ) 暗号化されたパーティションをマウントしてみてください。または、{{ic|cryptomount -u $crypto_uuid}} を使用して特定のパーティションをマウントしてください。その後、通常通り {{ic|insmod normal}} と {{ic|normal}} で進めてください。

正しいパスフレーズを入力したが {{ic|Invalid passphrase}} というエラーにより即座に戻される場合、正しい暗号化モジュールを指定していることを確認してください。{{ic|cryptsetup luksDump ''/dev/nvme0n1p2''}} を使って、ハッシュ関数 (SHA-256, SHA-512) とインストールされているモジュール ({{ic|gcry_sha256}}, {{ic|gcry_sha512}}) が一致するか、PBKDF アルゴリズムが pbkdf2 であるかを確認してください。{{ic|cryptsetup luksConvertKey --hash ''sha256'' --pbkdf pbkdf2 ''/dev/nvme0n1p2''}} を使えば、ハッシュと PBDKDF アルゴリズムを今あるキーに対して変更することができます。通常の状況では、パスフレーズが処理されるのに数秒掛かるはずです。

=== grub.cfg のカスタマイズ ===

このセクションでは ''grub-mkconfig'' に頼らずに {{ic|/boot/grub/grub.cfg}} 内にある GRUB のブートエントリーを手動で作成する方法について言及します。

基本的な GRUB の設定ファイルでは以下のオプションが使用されます。

* {{ic|(hd''X'',''Y'')}} はディスク ''X'' 上に存在するパーティション ''Y'' を表します。パーティション番号は 1 から始まり、ディスク番号は 0 から始まります。
* {{ic|1=set default=''N''}} は、ユーザーが操作せずにタイムアウトした後に選択されるデフォルトのブートエントリを表します。
* {{ic|1=set timeout=''M''}} は、ユーザーの選択が無かった場合に ''M'' 秒の間待ってデフォルトのブートエントリが起動されることを表します。
* {{ic|<nowiki>menuentry "title" {entry options}</nowiki>}} は {{ic|title}} というタイトルのブートエントリを表します。
* {{ic|1=set root=(hd''X'',''Y'')}} はカーネルと GRUB モジュールが格納されているブートパーティションを表します。(boot は分離されたパーティションである必要はなく、単に "root" パーティション ({{ic|/}}) 下にあるディレクトリを指定しても構いません)

==== LoaderDevicePartUUID ====

{{man|8|systemd-gpt-auto-generator}} が [[systemd#GPT パーティションの自動マウント|GPT パーティションの自動マウント]]をするために必要な {{ic|LoaderDevicePartUUID}} UEFI 変数を GRUB で設定するには、{{ic|grub.cfg}} で {{ic|bli}} モジュールをロードしてください:

{{bc|1=
if [ "$grub_platform" = "efi" ]; then
insmod bli
fi
}}

==== ブートメニューエントリの例 ====

{{Tip|以下のブートエントリは ''grub-mkconfig'' によって生成された {{ic|/boot/grub/grub.cfg}} でも使用可能です。以下を {{ic|/etc/grub.d/40_custom}} に追加して[[#メイン設定ファイルの生成|メインの設定ファイルを再生成]]するか、あるいは以下を直接 {{ic|/boot/grub/custom.cfg}} に追加してください。}}

複数の GRUB エントリーを管理するヒントとして、例えば {{Pkg|linux}} と {{Pkg|linux-lts}} カーネルを同時使用している場合は [[GRUB/ヒントとテクニック#複数のエントリ]] を見てください。

[[Archiso]] と [https://archboot.com Archboot] のブートメニューエントリについては [[マルチブート USB ドライブ#ブートエントリ]] を見てください。

===== GRUB コマンド =====

====== "Shutdown" メニューエントリ ======

{{bc|
menuentry "System shutdown" {
echo "System shutting down..."
halt
}
}}

====== "Restart" メニューエントリ ======

{{bc|
menuentry "System restart" {
echo "System rebooting..."
reboot
}
}}

====== "UEFI Firmware Settings" メニューエントリ ======

{{bc|1=
if [ ${grub_platform} == "efi" ]; then
menuentry 'UEFI Firmware Settings' --id 'uefi-firmware' {
fwsetup
}
fi
}}

===== EFI バイナリ =====

UEFI モードで起動している場合、GRUB は他の EFI バイナリをチェインロードできます。

{{Tip|1=GRUB が UEFI モードで起動している時にだけメニューエントリを表示するには、メニューエントリを {{ic|if}} 文で囲ってください:

{{bc|1=
if [ ${grub_platform} == "efi" ]; then
''UEFI のときだけ表示するメニューエントリをここへ''
fi
}}

}}

====== UEFI シェル ======

[[EFI システムパーティション]]直下に [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]] を置いてメニューエントリに追加すれば、UEFI シェルを起動できます:

{{bc|1=
menuentry "UEFI Shell" {
insmod fat
insmod chain
search --no-floppy --set=root --file /shellx64.efi
chainloader /shellx64.efi
}
}}

====== gdisk ======

[[gdisk#gdisk EFI アプリケーション|gdisk EFI アプリケーション]]をダウンロードして {{ic|gdisk_x64.efi}} を {{ic|''esp''/EFI/tools/}} にコピーしてください。

{{bc|1=
menuentry "gdisk" {
insmod fat
insmod chain
search --no-floppy --set=root --file /EFI/tools/gdisk_x64.efi
chainloader /EFI/tools/gdisk_x64.efi
}
}}

====== ユニファイドカーネルイメージをチェインロード ======

[[セキュアブート]]に従って生成したか他の方法によって生成した [[Unified カーネルイメージ]]を持っているならば、それをブートメニューに追加できます。例えば:

{{bc|1=
menuentry "Arch Linux" {
insmod fat
insmod chain
search --no-floppy --set=root --fs-uuid ''FILESYSTEM_UUID''
chainloader /EFI/Linux/arch-linux.efi
}
}}

===== デュアルブート =====

====== GNU/Linux ======

もう一つのディストリビューションが {{ic|sda2}} パーティションにあると仮定します:

{{bc|1=
menuentry "Other Linux" {
set root=(hd0,2)
linux /boot/vmlinuz (必要であれば追加のオプションをここへ)
initrd /boot/initrd.img (カーネルが必要とする/使用するイメージはここへ)
}
}}

代わりに UUID やファイルシステムのラベルで GRUB に正しいパーティションを探させるには:

{{bc|1=
menuentry "Other Linux" {
# UUID が 763A-9CB6 だとすると
search --no-floppy --set=root --fs-uuid 763A-9CB6

# OTHER_LINUX というラベルで探す (パーティションラベルが曖昧でないことを確認してください)
#search --no-floppy --set=root --label OTHER_LINUX

linux /boot/vmlinuz (必要であれば追加のオプションをここへ。例えば、root=UUID=763A-9CB6)
initrd /boot/initrd.img (カーネルが必要とする/使用するイメージはここへ)
}
}}

もう一つのディストリビューションが、インストール済みの GRUB と {{ic|grub.cfg}}、カーネル、initramfs のある有効な {{ic|/boot}} フォルダーをすでに持っているならば、GRUB にその {{ic|grub.cfg}} ファイルを起動中にその場で読み込ませることができます。例えば、{{ic|hd0}} と4番目の GPT パーティションの場合:

{{bc|1=
menuentry "configfile hd0,gpt4" {
insmod part_gpt
insmod btrfs
insmod ext2
set root='hd0,gpt4'
configfile /boot/grub/grub.cfg
}
}}

このエントリを選ぶと GRUB は他のボリュームからその {{ic|grub.cfg}} を読み込み、メニューを表示させます。{{ic|configfile}} ファイル内のコマンドによって環境変数が変更されても、{{ic|configfile}} から返ると環境変数の変更はすべて破棄されます。始めの GRUB メニューに戻る場合は {{ic|Esc}} を押してください。

====== UEFI/GPT モードでインストールされた Windows ======

このモードではメニューエントリが選択されると Windows ブートローダーの場所を発見し、GRUB のあとにブートローダーをチェインロードします。ここでするべきことは主に Windows の [[EFI システムパーティション]]を見つけて、そのパーティションから Windows のブートローダーを実行することです。

{{Note|このメニューエントリは、UEFI ブートモードで実行中であり、かつ Windows のビット数が UEFI のビット数と一致する場合にのみ機能します。BIOS モードでインストールされた GRUB では機能しません。さらなる情報については [[Windows と Arch のデュアルブート#Windows の UEFI と BIOS の制限]]と [[Windows と Arch のデュアルブート#ブートローダーの UEFI と BIOS の制限]] をご覧ください。}}

{{bc|1=
if [ "${grub_platform}" == "efi" ]; then
menuentry "Microsoft Windows Vista/7/8/8.1 UEFI/GPT" {
insmod part_gpt
insmod fat
insmod chain
search --no-floppy --fs-uuid --set=root $hints_string $fs_uuid
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
fi
}}

{{ic|$hints_string}} と {{ic|$fs_uuid}} は以下の2つのコマンドで得られます。

{{ic|$fs_uuid}} コマンドは EFI システムパーティションの UUID を割り出します。

{{hc|1=# grub-probe --target=fs_uuid ''esp''/EFI/Microsoft/Boot/bootmgfw.efi|2=
1ce5-7f28
}}

代わりに、{{ic|lsblk --fs}} を実行して、EFI システムパーティションの UUID をそこから読み込むこともできます。

{{ic|$hints_string}} コマンドは EFI システムパーティションの場所を割り出します。以下の例ではハードドライブ0にあります:

{{hc|1=# grub-probe --target=hints_string ''esp''/EFI/Microsoft/Boot/bootmgfw.efi|2=
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1
}}

以上の2つのコマンドでは Windows が使用する ESP が {{ic|''esp''}} にマウントされていると仮定しています。Windows である以上、Windows の EFI ファイルへのパスが異なる場合があるかもしれません。

====== BIOS/MBR モードでインストールされた Windows ======

{{Note|GRUB は {{ic|bootmgr}} ディレクトリの直接ブートをサポートしています。Windows を BIOS/MBR で起動するためにパーティションブートセクターを [https://www.gnu.org/software/grub/manual/grub.html#Chain_002dloading チェインロード]する必要はもはやありません。}}

{{Warning|{{ic|/bootmgr}} が存在する場所は '''システムパーティション''' であり、"本当"の Windows パーティション (通常、{{ic|C:}}) ではありません。システムパーティションの[[永続的なブロックデバイスの命名#by-label|ファイルシステムラベル]]は {{ic|System Reserved}} ({{ic|システムで予約済み}}) か {{ic|SYSTEM}} であり、サイズは約100~549 MiB 程度です。さらなる情報については [[Wikipedia:System partition and boot partition]] をご覧ください。}}

このセクションを通して Windows のパーティションは {{ic|/dev/sda1}} にあると仮定します。パーティションが異なる場合は {{ic|hd0,msdos1}} という記述をすべて変更してください。

{{Note|以下のメニューエントリは BIOS ブートモードでのみ機能します。UEFI モードでインストールされた GRUB では機能しません。[[Windows と Arch のデュアルブート#Windows の UEFI と BIOS の制限]] と [[Windows と Arch のデュアルブート#ブートローダーの UEFI と BIOS の制限]] をご覧ください。}}

両方の例で {{ic|''XXXX-XXXX''}} はファイルシステムの UUID を表しています。UUID は {{ic|lsblk --fs}} コマンドを使って得られます。実際の UUID に置き換えてください。

Windows Vista/7/8/8.1/10 では:

{{bc|1=
if [ "${grub_platform}" == "pc" ]; then
menuentry "Microsoft Windows Vista/7/8/8.1/10 BIOS/MBR" {
insmod part_msdos
insmod ntfs
insmod ntldr
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 ''XXXX-XXXX''
ntldr /bootmgr
}
fi
}}

Windows XP では:

{{bc|1=
if [ "${grub_platform}" == "pc" ]; then
menuentry "Microsoft Windows XP" {
insmod part_msdos
insmod ntfs
insmod ntldr
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 ''XXXX-XXXX''
ntldr /ntldr
}
fi
}}

{{Note|GRUB をインストールすると Windows 8 が汚染される場合があります。この場合、{{ic|\boot\bcd}} (エラーコード {{ic|0xc000000f}})のエラーにより Windows が起動できなくなります。これを直すには Windows 回復コンソール(インストールディスク上にある {{ic|cmd.exe}})を開いて、以下を実行してください:

X:\> bootrec.exe /fixboot
X:\> bootrec.exe /RebuildBcd

{{ic|bootrec.exe /Fixmbr}} を'''実行しない'''でください。GRUB が吹き飛びます。
あるいは、トラブルシューティングメニューにあるスタートアップ修復機能を使用できます。これは GRUB を吹き飛ばしませんし、ほとんどのエラーを修復します。
また、対象のハードドライブとブート可能ドライブの両方'''だけ'''を接続しておくほうが良いでしょう。通常、他のデバイスが接続されていると Windows はブート情報の修復に失敗します。
}}

===== ラベルを使う =====

{{ic|search}} コマンドに対して {{ic|--label}} オプションを使えば、ファイルシステムに付けられた人間が読みやすい文字列であるラベルを使うことができます。まずはじめに、[[永続的なブロックデバイスの命名#by-label|ファイルシステムにラベルがあることを確認]]してください。

そして、ラベルを使ってエントリを追加してください。例えば:

menuentry "Arch Linux, session texte" {
search --label --set=root archroot
linux /boot/vmlinuz-linux root=/dev/disk/by-label/archroot ro
initrd /boot/initramfs-linux.img
}

== コマンドシェルを使う ==

GRUB のモジュールを全て保存するには MBR は小さすぎるので、メニューと基本的なコマンドだけが MBR に入っています。GRUB の機能のほとんどは {{ic|/boot/grub}} 内のモジュールとして存在し、必要に応じて挿入されます。エラー状態になると (例: パーティションレイアウトが変更された場合)、GRUB が起動に失敗する場合があります。このとき、コマンドシェルが表示されます。

GRUB は複数のシェル/プロンプトを提供しています。メニューの読込に問題があってもブートローダがディスクを見つけられるときは、おそらく "normal" シェルに落とされるでしょう:

grub>

さらに深刻な問題 (例: GRUB が必要なファイルを見つけられないなど) があるときは、代わりに "rescue" シェルに落とされるでしょう:

grub rescue>

rescue シェルは通常のシェルの制限されたサブセットで、使える機能が非常に少なくなっています。rescue シェルが出てきた時は、まず "normal" モジュールの挿入を試して、"normal" シェルを起動してみて下さい:

grub rescue> set prefix=(hdX,Y)/boot/grub
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod
rescue:grub> normal

=== ページャのサポート ===

GRUB はページャをサポートしており長い出力をするコマンド ({{ic|help}} コマンドなど) を読むことができます。これは通常のシェルモードでしか動作せずレスキューモードでは使えません。ページャを有効にするには、GRUB コマンドシェルで次を入力して下さい:

sh:grub> set pager=1

=== コマンドシェル環境を使ってオペレーティングシステムを起動する ===

grub>

GRUB のコマンドシェル環境を使ってオペレーティングシステムを起動することが可能です。
通常は'''チェインロード'''を使ってドライブやパーティションから Windows / Linux を起動するということが考えられます。

''チェインロード''は現在のブートローダから別のブートローダをロードすることを意味します。

他のブートローダーは、パーティショニングされたディスク (MBR) の先頭や、パーティションレスディスク (VBR) のパーティションの先頭に組み込んだり、あるいは UEFI の場合は EFI バイナリとして組み込むことができます。

==== パーティションの VBR をチェインロード ====

set root=(hdX,Y)
chainloader +1
boot

X=0,1,2...
Y=1,2,3...

例えば最初のハードディスクの最初のパーティションに保存された Windows をチェインロードするには:

set root=(hd0,1)
chainloader +1
boot

同じようにパーティションにインストールされた GRUB をチェインロードすることもできます。

==== ディスクの MBR やパーティションレスディスクの VBR をチェインロード ====

set root=hdX
chainloader +1
boot

==== UEFI モードでインストールされた Windows/Linux のチェインロード ====

insmod fat
set root=(hd0,gpt4)
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi
boot

{{ic|insmod fat}} は、EFI システムパーティション上の Windows ブートローダーにアクセするために、FAT ファイルシステムモジュールをロードするために使用されます。
{{ic|(hd0,gpt4)}} (すなわち {{ic|/dev/sda4}}) は、この例における EFI システムパーティションです。
{{ic|chainloader}} 行のエントリは、チェインロードすべき ''.efi'' ファイルへのパスを指定しています。

==== 通常のロード ====

[[#rescue コンソールを使う]] の例を見て下さい。

=== rescue コンソールを使う ===

まず [[#コマンドシェルを使う]] を見て下さい。標準シェルを有効にできない場合、ライブ CD や他のレスキューディスクを使って起動し、設定のエラーを直して GRUB を再インストールという方法があります。ただし、そのようなブートディスクはいつも使えるというわけではありません (もしくは必要ありません); レスキューコンソールは驚くほど堅牢です。

GRUB rescue で利用できるコマンドには {{ic|insmod}}、{{ic|ls}}、{{ic|set}}、{{ic|unset}} があります。この例では {{ic|set}} と {{ic|insmod}} を使います。{{ic|set}} は変数を変更し {{ic|insmod}} は新しいモジュールを挿入して機能を追加します。

始める前に、ユーザーは自分の {{ic|/boot}} パーティションの位置を知っていなければなりません (分割パーティションなのか、root 下のサブディレクトリなのか):

grub rescue> set prefix=(hd''X'',''Y'')/boot/grub

{{ic|''X''}} は物理ドライブ番号、{{ic|''Y''}} はパーティション番号に置き換えてください。

{{Note|boot パーティションを分割している場合、パスから {{ic|/boot}} を省いて下さい (つまり、{{ic|1=set prefix=(hd''X'',''Y'')/grub}} と入力する)。}}

コンソールの機能を拡張するために、{{ic|linux}} モジュールを挿入します:

grub rescue> insmod i386-pc/linux.mod

もしくは、単純に:

grub rescue> insmod linux

これで、より親しみのあるであろう {{ic|linux}} と {{ic|initrd}} のコマンドが使えます。

例えば、Arch Linux を起動する場合:

set root=(hd0,5)
linux /boot/vmlinuz-linux root=/dev/sda5
initrd /boot/initramfs-linux.img
boot

boot パーティションを分割している (例えば、UEFI を使用している場合など) なら、行を適宜変更する必要があります:

{{Note|boot は別のパーティションであり、ルートパーティションの一部ではないので、上の prefix 変数と同じような形式で boot パーティションを手動で指定する必要があります。}}

set root=(hd0,5)
linux (hd''X'',''Y'')/vmlinuz-linux root=/dev/sda6
initrd (hd''X'',''Y'')/initramfs-linux.img
boot

{{Note|{{ic|linux}} コマンドの実行中に {{ic|error: premature end of file /YOUR_KERNEL_NAME}} と表示される場合は、代わりに {{ic|linux16}} を使ってみて下さい。}}

Arch Linux 環境のブートに成功したら、必要に応じて {{ic|grub.cfg}} を修正し GRUB を再インストールすることができます。

GRUB を再インストールして問題を完全に修正するには、必要応じて {{ic|/dev/sda}} を変更してください。詳しくは [[#インストール]] を見て下さい。

== GRUB を消去 ==

=== UEFI システム ===

''grub'' を削除する前に、他のブートローダがインストールされていて、GRUB の後を引き継ぐように設定されていることを確認してください。

{{hc|$ efibootmgr|
BootOrder: 0003,0001,0000,0002
Boot0000* Windows Boot Manager HD(2,GPT,4dabbedf-191b-4432-bc09-8bcbd1d7dabf,0x109000,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)
Boot0001* GRUB HD(2,GPT,4dabbedf-191b-4432-bc09-8bcbd1d7dabf,0x109000,0x32000)/File(\EFI\GRUB\grubx64.efi)
Boot0002* Linux-Firmware-Updater HD(2,GPT,5dabbedf-191b-4432-bc09-8bcbd1d7dabf,0x109000,0x32000)/File(\EFI\arch\fwupdx64.efi)
Boot0003* Linux Boot Manager HD(2,GPT,4dabbedf-191b-4432-bc09-8bcbd1d7dabf,0x109000,0x32000)/File(\EFI\systemd\systemd-bootx64.efi)
}}

{{ic|BootOrder}} で ''grub'' が最初のエントリになっている場合、[[systemd-boot]] などの他のブートローダをインストールして最初のエントリにしてください。その後、''bootnum'' を使って ''grub'' を削除することができます。

# efibootmgr --delete-bootnum -b 1

また、{{ic|''esp''/EFI/grub}} と {{ic|/boot/grub}} ディレクトリも削除してください。

=== BIOS システム ===

''grub'' を他の BIOS ブートローダに置き換えるには、単に新しいブートローダをインストールしてください (そうすることで、[[パーティショニング#Master Boot Record (bootstrap code)|MBR ブートコード]]が上書きされます)。

{{ic|grub-install}} は {{ic|/boot/grub}} ディレクトリを作成するので、これは手動で削除する必要があります。しかし、''grub'' をまたインストールするかもしれない場合は、このディレクトリを残しておいたほうが良いかもしれません。

UEFI/GPT に移行した後は、[[dd#ブートローダーの削除|dd を使って MBR ブートコードを削除する]]ことができます。

== トラブルシューティング ==

=== サポートのないファイルシステム ===

GRUB が root のファイルシステムをサポートしていない場合、代替の {{ic|/boot}} パーティションをサポートのあるファイルシステムで作成する必要があります。開発バージョンの GRUB である {{aur|grub-git}} が該当するファイルシステムをネイティブサポートしている場合があります。

サポートされないファイルシステムで GRUB を使用した場合、ドライブの [[UUID]] を抽出できないため、GRUB は古典的で非永続的な {{ic|/dev/''sdXx''}} 名を使います。この場合、{{ic|/boot/grub/grub.cfg}} を手動で編集し、{{ic|1=root=/dev/''sdXx''}} を {{ic|1=root=UUID=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX''}} のように置き換える必要があるかもしれません。{{ic|blkid}} コマンドを使えばデバイスの UUID を得られます。[[永続的なブロックデバイスの命名]] を見てください。

GRUB はバージョン 2.0.4 より [[F2FS]] をサポートしていますが、{{ic|extra_attr}} フラグを有効にして作成された F2FS パーティションからブートファイルを正しく読み込むことができません。

=== デバッグメッセージを有効にする ===

{{Note|この変更は[[#メイン設定ファイルの生成|メインの設定ファイルを生成]]すると上書きされます。}}

以下を {{ic|grub.cfg}} に追加してください:

set pager=1
set debug=all

=== msdos-style エラーメッセージ ===

grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding will not be possible!
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.
However, blocklists are UNRELIABLE and its use is discouraged.
grub-setup: error: If you really want blocklists, use --force.

このエラーは VMware コンテナに GRUB をインストールしようとすると起こることがあります。詳しくは [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 ここ] を読んで下さい。最初のパーティションが MBR (ブロック 63) のすぐ後ろから始まっていて、最初のパーティションの前に通常の 1 MiB のスペース (2048 ブロック) がない場合に起こります。[[#Master Boot Record (MBR) 特有の手順]] を読んで下さい。

=== UEFI ===

==== よくあるインストール時のエラー ====

* 一部の UEFI デバイスで起こりうるエラーは、{{ic|Could not prepare Boot variable: Read-only file system}} です。{{ic|/sys/firmware/efi/efivars}} を読み書き可能な状態で再マウントする必要があります。{{bc|# mount -o remount,rw,nosuid,nodev,noexec --types efivarfs efivarfs /sys/firmware/efi/efivars}} [[ブートローダー]]のインストールに関しては [[Gentoo:Handbook:AMD64/Installation/Bootloader#Install|Gentoo Wiki]] を見てください。
* ''sysfs'' か ''procfs'' がある状態で ''grub-install'' を実行すると問題が発生し、{{ic|modprobe efivarfs}} を実行しなければならないと言われる場合、[[Unified Extensible Firmware Interface#efivarfs のマウント|efivarfs をマウント]]して上記のコマンドを実行してみてください。
* {{ic|--target}} と {{ic|--directory}} オプションのどちらかがないと、{{ic|grub-install}} はどこにファームウェアをインストールすればいいのか決められません。そのような場合 {{ic|grub-install}} は {{ic|source_dir does not exist. Please specify --target or --directory}} というメッセージを表示します。
* grub-install の実行後に {{ic|error: ''esp'' doesn't look like an EFI partition}} と表示される場合、おそらくパーティションが [[FAT32]] でフォーマットされていません。

==== ファームウェアブートマネージャーに GRUB エントリを作成する ====

{{ic|grub-install}} は自動的にブートマネージャーにメニューエントリを追加しようと試みます。もし GRUB がそれを行わない場合、[[UEFI#efibootmgr]] を見て、{{ic|efibootmgr}} を使ってメニューエントリを作成する指示を読んでください。しかし、[[UEFI#ISO から UEFI ブータブル USB を作成する]] にあるように、よくある原因は CD/USB を UEFI モードで起動していないというものです。

GRUB エントリをファームウェアブートマネージャに作成する例として、{{ic|efibootmgr -c}} を考えてみましょう。これは、{{ic|/dev/sda1}} が EFI システムパーティションであり、{{ic|/boot/efi}} にマウントされていると仮定します。これは {{ic|efibootmgr}} のデフォルトの挙動です。このツールは、("Linux" という名前の) 新しいブートオプションを作成し、それをブート順序リストの1番目に配置します。オプションを渡すことでデフォルトの挙動を変更できます。デフォルトの OS ローダーは {{ic|\EFI\arch\grub.efi}} です。

==== レスキューシェルが起動する ====

GRUB はロードされたが、エラーが表示されずにレスキューシェルに落とされる場合、以下の2つの理由のうち1つが原因である可能性があります:

* {{ic|grub.cfg}} が存在しないか、場所を間違えている。{{ic|--boot-directory}} を使って GRUB UEFI をインストールして、{{ic|grub.cfg}} が存在しない場合に起こります。
* ブートパーティションが変更された ({{ic|grubx64.efi}} ファイルにハードコードされています)。

==== GRUB UEFI がロードされない ====

有効な UEFI の例:

{{hc|# efibootmgr -u|
BootCurrent: 0000
Timeout: 3 seconds
BootOrder: 0000,0001,0002
Boot0000* GRUB HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EFI\GRUB\grubx64.efi)
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\shellx64.efi)
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI
}}

画面が数秒間真っ暗になって、その後、次のブートオプションが試行される場合、[https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 この投稿]によると、GRUB をルートパーティションに移動することで直るかもしれません。ブートオプションは削除して後でまた作成する必要があります。GRUB のエントリは次のようにしてください:

Boot0000* GRUB HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grubx64.efi)

==== デフォルト/フォールバックのブートパス ====

一部の UEFI ファーウェアではブート可能なファイルが既知の場所に存在している必要があり、それ以外の場所では UEFI NVRAM ブートエントリに表示されません。この場合、{{ic|grub-install}} が、GRUB を起動するエントリが {{ic|efibootmgr}} によって追加されたと報告するでしょうが、VisualBIOS のブート順序セレクターには表示されません。解決策は GRUB をデフォルト/フォールバックのブートパスにインストールすることです:

# grub-install --target=x86_64-efi --efi-directory=''esp'' '''--removable'''

あるいは、すでにインストールされた GRUB の EFI 実行ファイルをデフォルト/フォールバックのパスに移動することができます:

# mv ''esp''/EFI/grub ''esp''/EFI/BOOT
# mv ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/BOOTX64.EFI

=== Invalid signature ===

(例えば、パーティションを再設定したり、追加のハードドライブを追加したりしたあとで) Windows を起動しようとして "invalid signature" エラーが発生する場合、GRUB のデバイス設定を移動 (削除) し、GRUB に再設定させてください:

# mv /boot/grub/device.map /boot/grub/device.map-old
# grub-mkconfig -o /boot/grub/grub.cfg

これで {{ic|grub-mkconfig}} は Windows を含む全てのブートオプションを記述したはずです。これで動作したら、{{ic|/boot/grub/device.map-old}} は削除してください。

=== 起動中にフリーズする ===

GRUB がカーネルと初期 RAM ディスクをロードした後に、エラーメッセージが表示されずにフリーズする場合、{{ic|add_efi_memmap}} カーネルパラメータを削除してみてください。

=== 他の OS から Arch が見つからない ===

他のディストリビューションで {{ic|os-prober}} を使って Arch Linux を自動的に検索できないという報告が複数確認されています。この問題が発生する場合、{{ic|/etc/lsb-release}} をおくことで検知が改善されると報告されています。このファイルと更新ツールは[[公式リポジトリ]]にある {{Pkg|lsb-release}} パッケージから利用可能です。

=== chroot でインストールした時に警告が表示される ===

(システムのインストール中などに) chroot 環境で LVM システム上に GRUB をインストールする際に、以下のような警告が発生する場合があります:

/run/lvm/lvmetad.socket: connect failed: No such file or directory

または

WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.

これは、{{ic|/run}} が chroot 内で利用可能でないから起こります。すべてが正しく行われていれば、これらの警告のせいでシステムが起動できなくなることはありません。インストールを継続することができます。

=== GRUB のロードが遅い ===

ディスク容量が残りわずかの場合 GRUB がロードされるのにかなり時間がかかることがあります。起動が遅い場合 {{ic|/boot}} や {{ic|/}} に十分な空き容量があるか確認してください。

=== error: unknown filesystem ===

GRUB が {{ic|error: unknown filesystem}} と出力して起動しない理由はいくつか考えられます。[[UUID]] が正しいこと、全てのファイルシステムが問題なく、GRUB によってサポートされていることが確認できる場合、[[#GUID Partition Table (GPT) 特有の手順|BIOS Boot Partition]] がドライブの最初の 2TB の中にない可能性があります [https://bbs.archlinux.org/viewtopic.php?id=195948]。適当なパーティショニングツールを使ってパーティションが最初の 2TB 以内にあるようにして、GRUB を再インストール・再設定してください。

また、このエラーは [[ext4]] ファイルシステムがいくつかの機能をサポートしていないことが原因かもしれません:
* {{ic|large_dir}} - サポートされません。
* {{ic|metadata_csum_seed}} - GRUB 2.11 でサポートされます ([https://git.savannah.gnu.org/cgit/grub.git/commit/?id=7fd5feff97c4b1f446f8fcf6d37aca0c64e7c763 コミット]).

{{Warning| {{ic|/boot}} ファイルシステム上で[[ファイルシステム]]の新しい機能を有効化する前に、GRUB がそれらをサポートしていることを確認してください。}}

=== grub-reboot で再設定されない ===

GRUB は Btrfs のルートパーティションに書き込むを行うことができません [https://bbs.archlinux.org/viewtopic.php?id=166131]。grub-reboot を使って他のエントリを起動した場合、ディスク上の環境を更新することができなくなります。(ディストリビューションを切り替えるなどの場合に) 他のエントリから grub-reboot を実行するか他のファイルシステムを使ってください。{{ic|grub-editenv create}} を実行して {{ic|/etc/default/grub}} に {{ic|GRUB_DEFAULT<nowiki>=</nowiki>0}} を設定することでエントリをリセットできます (設定後は {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} を行ってください)。

=== 古い Btrfs のせいでインストールができない ===

パーティションテーブルを作成しないで Btrfs を使ってドライブをフォーマットしている場合 (例: {{ic|/dev/sdx}})、後からパーティションテーブルを書き込むと、Btrfs のフォーマットが一部残留します。ほとんどのユーティリティや OS は残留した Btrfs を認識できないため、GRUB は (たとえ --force が付けられていても) インストールを拒否します:

# grub-install: warning: Attempting to install GRUB to a disk with multiple partition labels. This is not supported yet..
# grub-install: error: filesystem `btrfs' does not support blocklists.

ドライブを完全に消去してもいいですが、{{ic|wipefs -o 0x10040 /dev/sdx}} を使えばデータを残して Btrfs のスーパーブロックだけを消去することができます。

=== Windows 8/10 が認識されない ===

Windows 8/10 の "高速スタートアップ"、"ハイブリッドブート"、"Hiberboot" と呼ばれる設定を有効にしていると Windows のパーティションをマウントすることができなくなる可能性があります。そのため {{ic|grub-mkconfig}} が Windows を認識することができなくなります。Windows で高速スタートアップを無効化することで GRUB のメニューに追加することができるようになるはずです。

=== grub-rescue プロンプトと暗号化済み /boot ===

[[#暗号化された /boot|暗号化済みの /boot]] を使用している場合に間違ったパスワードを入力してしまうと grub-rescue プロンプトに入ります。

この grub-rescue プロンプトではできることが限られています。以下のコマンドを使ってブートを完了させます:

{{bc|
grub rescue> cryptomount <partition>
grub rescue> insmod normal
grub rescue> normal
}}

より良い説明は[https://blog.stigok.com/2017/12/29/decrypt-and-mount-luks-disk-from-grub-rescue-mode.html このブログ投稿]{{Dead link|2023|04|23|status=404}}をご覧ください。

=== GRUB をインストールしたが起動時にメニューが表示されない ===

{{ic|/etc/default/grub}} を見て {{ic|GRUB_TIMEOUT}} が {{ic|0}} に設定されていないかチェックしてください。{{ic|0}} に設定されていた場合、正の数に設定し直してください。この値はデフォルトの GRUB エントリが起動されるまでの秒数を表しています。{{ic|GRUB_TIMEOUT_STYLE}} が {{ic|hidden}} に設定されていないかもチェックしてください。{{ic|hidden}} に設定されていた場合、{{ic|menu}} に設定し直してください。これでメニューがデフォルトで表示されるようになります。以上が終わったら、[[#メイン設定ファイルの生成|メインの設定ファイルを再生成]]して、再起動してメニューが表示されるか確かめてください。

これでうまく行かない場合、グラフィカルターミナルとの互換性の問題があるのかもしれません。{{ic|/etc/default/grub}} で {{ic|GRUB_TERMINAL_OUTPUT}} を {{ic|console}} に設定し、GRUB のグラフィカルターミナルを無効化してください。

== 参照 ==

* [[Wikipedia:ja:GNU GRUB]]
* [https://www.gnu.org/software/grub/manual/grub.html 公式 GRUB マニュアル]
* [https://help.ubuntu.com/community/Grub2 Ubuntu wiki の GRUB ページ]
* [https://help.ubuntu.com/community/UEFIBooting UEFI システム用にコンパイルする手順を説明している GRUB wiki ページ]
* [[Wikipedia:BIOS Boot partition]]
* [https://web.archive.org/web/20160424042444/http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html#Editing_etcgrub.d05_debian_theme How to configure GRUB]

{{TranslationStatus|GRUB|2024-08-26|812848}}

GRUB

2026-08-09T07:57:03Z

ELC: /* Shim-lock */ モジュール名が日本語に翻訳されていたのを修正

[[Category:ブートローダー]]
[[Category:GNU]]
[[de:GRUB]]
[[en:GRUB]]
[[es:GRUB]]
[[pl:GRUB]]
[[pt:GRUB]]
[[ru:GRUB]]
[[zh-hans:GRUB]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Master Boot Record}}
{{Related|GUID Partition Table}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|GRUB Legacy}}
{{Related|GRUB/EFI サンプル}}
{{Related|GRUB/ヒントとテクニック}}
{{Related|マルチブート USB ドライブ}}
{{Related articles end}}
[https://www.gnu.org/software/grub/ GRUB] (GRand Unified Bootloader) は[[ブートローダー]]です。現在の GRUB は '''GRUB 2''' とも呼ばれています。元の GRUB ([[GRUB Legacy]]) はバージョン 0.9x に対応しています。このページでは GRUB 2 についてのみ説明します。

{{Note|この記事全体で、{{ic|''esp''}} は [[EFI システムパーティション]] (別名 ESP) のマウントポイントを表します。}}

== サポートされているファイルシステム ==

GRUB には[https://www.gnu.org/software/grub/manual/grub/html_node/Features.html#Features 複数のファイルシステム] (特に重要なものとしては [[FAT32]]、[[ext4]]、[[Btrfs]]、[[XFS]]) に対する独自のサポートがあります。注意事項に関しては [[#サポートのないファイルシステム]] 章を見てください。

{{Warning|ファイルシステムには、GRUB がまだ対応していない新しい機能が導入されることがあります。その場合、GRUB と互換性の無い機能を無効化しない限り、そのファイルシステムを {{ic|/boot}} に対して使用するべきではありません。この問題は、[[パーティショニング#/boot|/boot パーティション]]を別に分けて、[[FAT32]] などの広くサポートされているファイルシステムを使用することで、回避することができます。}}

== UEFI システム ==

{{Note|
* 次のページを読んで理解しておくことをおすすめします: [[Unified Extensible Firmware Interface]]、[[パーティショニング#GUID Partition Table]]、[[Arch ブートプロセス#UEFI_2]]。
* UEFI を使うようにインストールする場合、Arch のインストールメディアを UEFI モードで起動することが重要です。さもないと、''efibootmgr'' が GRUB の UEFI ブートエントリを追加できません。[[#デフォルト/フォールバックのブートパス|フォールバックブートパス]]へのインストールは NVRAM を使用しないため、BIOS モードでも可能です。
* UEFI を使用してディスクから起動するには EFI システムパーティションが必要です。[[EFI システムパーティション#既存のパーティションの確認]] に従って、すでに EFI システムパーティションが存在するかどうかを確認してください。存在しない場合は作成する必要があります。
* この記事全体で、{{ic|insmod}} を使って追加の GRUB2 モジュールを挿入可能であると仮定しています。[[#Shim-lock]] で議論されているように、これはセキュアブートが有効化されている UEFI システムには当てはまりません。セキュアブートシステム上で標準の GRUB EFI ファイル {{ic|grubx64.efi}} に含まれていない追加の GRUB モジュールを使用したい場合は、{{ic|grub-mkstandalone}} を使って追加の GRUB モジュールを含めた GRUB EFI {{ic|grubx64.efi}} を再生成しなければなりません。
}}

=== インストール ===

{{Note|
* UEFI の実装はマザーボード製造者ごとに異なっています。以下で説明されている手順は広い範囲の UEFI システムで動作するように意図されています。しかし、この方法を適用しているにも関わらず問題が発生する場合は、あなたのハードウェア固有のケースにおける詳細な情報を (可能であれば解決策も) 共有することが推奨されます。そのようなケースのために [[GRUB/EFI サンプル]] の記事が提供されています。
* このセクションでは、あなたが x64 (64 ビット) UEFI のシステムに対して GRUB をインストールしようとしていると仮定します。IA32 (32 ビット) UEFI の場合は (32 ビット CPU と混同しないでください)、適切な場所で {{ic|x86_64-efi}} を {{ic|i386-efi}} に置き換えてください。[[Unified Extensible Firmware Interface#UEFI ファームウェアのビット数を調べる]] の手順を見て、UEFI のビット数を調べてください。
}}

まず、{{Pkg|grub}} と {{Pkg|efibootmgr}} を[[インストール]]してください。''GRUB'' はブートローダである一方、''efibootmgr'' はブートエントリを NVRAM に書き込むために GRUB のインストールスクリプトによって使用されます。

そして、以下の手順に従って GRUB をディスクにインストールしてください:

# [[EFI システムパーティション#パーティションのマウント|EFI システムパーティションをマウント]]してください。そして、このセクションの後の部分で出てくる {{ic|''esp''}} という記述をそのマウントポイントに置き換えてください。
# ブートローダの識別子を選んでください、ここでは仮に {{ic|GRUB}} としましょう。{{ic|''esp''/EFI/}} にあなたが選んだものと同じ名前のディレクトリが作成され、そこに EFI バイナリが格納されます。その名前が UEFI ブートメニューの GRUB ブートエントリの名前になります。
# 以下のコマンドを実行して、GRUB EFI アプリケーション {{ic|grubx64.efi}} を {{ic|''esp''/EFI/GRUB/}} に、モジュールを {{ic|/boot/grub/x86_64-efi/}} にインストールしてください。
::{{Note|
::* GRUB をブートローダとしてインストールするシステム内でパッケージをインストールし、{{ic|grub-install}} を実行してください。つまり、ライブインストール環境から起動している場合、{{ic|grub-install}} は (インストール先の) chroot 環境の中で実行する必要があるということです。何らかの理由で、インストールされたシステムの外で {{ic|grub-install}} を実行する必要がある場合、マウントした {{ic|/boot}} ディレクトリへのパスを {{ic|1=--boot-directory=}} オプションに渡してください。例: {{ic|1=--boot-directory=/mnt/boot}}
::* 一部のマザーボードは、空白を含む {{ic|bootloader-id}} を扱うことができません。}}
::{{bc|1=# grub-install --target=x86_64-efi --efi-directory=''esp'' --bootloader-id=GRUB}}

上記のインストール作業が完了した後、メインの GRUB ディレクトリが {{ic|/boot/grub/}} に作成されています。別の場所を指定する方法については [[GRUB/ヒントとテクニック#代替インストール方法]] を見てください。{{ic|grub-install}} は[[#ファームウェアブートマネージャーに GRUB エントリを作成する|ファームウェアのブートマネージャにもエントリを作成]]しようとすることに注意してください。その名前は上記の例では {{ic|GRUB}} となります。しかし、ブートエントリが埋まっていると、これは失敗します。この場合は [[efibootmgr]] を使って必要ないエントリを削除してください。

設定を確定したあとに[[#メイン設定ファイルの生成|メインの設定ファイルを生成]]することを忘れないでください。

{{Tip|{{ic|--removable}} オプションを使うと、GRUB は {{ic|''esp''/EFI/BOOT/BOOTX64.EFI}} にインストールされます ({{ic|i386-efi}} ターゲットの場合は {{ic|''esp''/EFI/BOOT/BOOTIA32.EFI}})。その結果、EFI 変数がリセットされた場合やドライブを他のコンピュータに移した場合でもそのドライブから起動することができるようになります。通常は BIOS を使用する方法と同じようにドライブを選択することで使うことができます。Windows とデュアルブートする場合、Windows は通常そこに EFI 実行ファイルを配置するので注意してください。とはいえ、そのファイルは Windows の UEFI ブートエントリを再生成するためだけに使用されます。[[Mac]] 上に GRUB をインストールする場合、このオプションを使用する必要があります。一部のデスクトップマザーボード (特に MSI のマザーボード) はここに保存されている EFI 実行ファイルしか見ないので、このオプションが必須になります。
UEFI アップデートを実行すると、既存の UEFI ブートエントリが削除されるかもしれません。なので、"removable" なブートエントリを有効化しておくと、それをフォールバックとして利用できます。}}

{{Note|
* {{ic|--efi-directory}} と {{ic|--bootloader-id}} は GRUB UEFI 専用です。{{ic|--efi-directory}} は、非推奨となった {{ic|--root-directory}} を置き換えます。
* {{ic|grub-install}} コマンドに ''device_path'' オプション (例えば {{ic|/dev/sda}}) が無いことに気付いたかもしれません。実際、''device_path'' は GRUB EFI インストールスクリプトによって無視されます。UEFI ブートローダーは MBR ブートコードもパーティションブートセクタも全く使用しないのです。
}}

問題が発生した場合は [[#UEFI|UEFI のトラブルシューティング]] を見て下さい。加えて [[GRUB/ヒントとテクニック#UEFI の詳細情報]] も参照してください。

=== セキュアブートサポート ===

GRUB は、CA 鍵か shim のいずれかを使用するセキュアブートを完全にサポートしています。しかし、インストールのコマンドは、どちらを使用するかによって異なります。

{{Warning|
* [[セキュアブート]]を不適切に設定すると、システムが起動不能になる可能性があります。セキュアブートを有効化した後に何らかの理由により起動できなくなった場合、ファームウェアでセキュアブートを無効化し、システムを再起動する必要があります。
* ブートローダで不必要なモジュールをロードすると、セキュリティリスクを発生させる可能性があります。これらのコマンドは、必要なときにだけ使用してください。
}}

==== CA 鍵 ====

CA 鍵を使うには、インストールのコマンドは次のようになります:

# grub-install --target=x86_64-efi --efi-directory=''esp'' --bootloader-id=GRUB --modules="tpm" --disable-shim-lock

==== Shim-lock ====

{{Note|このセクションに進む前に、[[セキュアブート#shim]] に書かれてある指示の通りにし、{{pkg|sbsigntools}} をセットアップして鍵を受け取る準備を整えておく必要があります。}}

Shim-lock を使用する場合、GRUB をセキュアブートモードでブートさせるには、[[vmlinuz]] と [[initramfs]] のイメージが含まれているファイルシステムを読むために必要なモジュール全てが GRUB のバイナリに含まれていなければなりません。

GRUB バージョン {{ic|2.06.r261.g2f4430cc0}} から、セキュアブートモードで {{ic|insmod}} を使ってモジュールをロードすることは許可されなくなりました (任意のコードをサイドロードできてしまう可能性があるからです)。GRUB モジュールが EFI バイナリ内に組み込まれていない場合、GRUB はそれらのモジュールをサイドロード/{{ic|insmod}} しようと試み、その結果、以下のようなメッセージにより GRUB の起動が失敗します:

error: prohibited by secure boot policy

[https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian/build-efi-images?h=debian/2.06-2ubuntu12 Ubuntu の公式ビルドスクリプト]によると、Ubuntu では以下の GRUB モジュールが署名済み GRUB EFI バイナリ {{ic|grubx64.efi}} に組み込まれています:

* [https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian/build-efi-images?h=debian/2.06-2ubuntu12#n87 "基本" モジュール]。CD や簡単にパーティショニングされたディスクからブートするために必要: {{ic|all_video}}、{{ic|boot}}、{{ic|btrfs}}、{{ic|cat}}、{{ic|chain}}、{{ic|configfile}}、{{ic|echo}}、{{ic|efifwsetup}}、{{ic|efinet}}、{{ic|ext2}}、{{ic|fat}}、{{ic|font}}、{{ic|gettext}}、{{ic|gfxmenu}}、{{ic|gfxterm}}、{{ic|gfxterm_background}}、{{ic|gzio}}、{{ic|halt}}、{{ic|help}}、{{ic|hfsplus}}、{{ic|iso9660}}、{{ic|jpeg}}、{{ic|keystatus}}、{{ic|loadenv}}、{{ic|loopback}}、{{ic|linux}}、{{ic|ls}}、{{ic|lsefi}}、{{ic|lsefimmap}}、{{ic|lsefisystab}}、{{ic|lssal}}、{{ic|memdisk}}、{{ic|minicmd}}、{{ic|normal}}、{{ic|ntfs}}、{{ic|part_apple}}、{{ic|part_msdos}}、{{ic|part_gpt}}、{{ic|password_pbkdf2}}、{{ic|png}}、{{ic|probe}}、{{ic|reboot}}、{{ic|regexp}}、{{ic|search}}、{{ic|search_fs_uuid}}、{{ic|search_fs_file}}、{{ic|search_label}}、{{ic|sleep}}、{{ic|smbios}}、{{ic|squash4}}、{{ic|test}}、{{ic|true}}、{{ic|video}}、{{ic|xfs}}、{{ic|zfs}}、{{ic|zfscrypt}}、{{ic|zfsinfo}}
* x84_64-efi アーキテクチャ用の [https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian/build-efi-images?h=debian/2.06-2ubuntu12#n147 "プラットフォーム固有" のモジュール]。例えば:
** {{ic|play}}: ブート中に音を鳴らす
** {{ic|cpuid}}: ブート時に CPU の機能を確認する
** {{ic|tpm}}: Measured Boot / [[TPM|Trusted Platform Modules]] をサポートする
* [https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian/build-efi-images?h=debian/2.06-2ubuntu12#n159 "高度な" モジュール]。以下が含まれます:
** {{ic|cryptodisk}}: [[dm-crypt|plain モードで暗号化された]]ディスクからブートする
** {{ic|gcry_algorithm}}: 特定のハッシュアルゴリズムと暗号化アルゴリズムをサポートする
** {{ic|luks}}: [[LUKS]] で暗号化されたディスクからブートする
** {{ic|lvm}}: [[LVM]] 論理ボリュームディスクからブートする
** {{ic|mdraid09}}、{{ic|mdraid1x}}、{{ic|raid5rec}}、{{ic|raid6rec}}: [[RAID]] 仮想ディスクからブートする

GRUB モジュールのリストはシェル変数の形にしなければなりません (ここでは {{ic|GRUB_MODULES}} と表記しています)。[https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian/build-efi-images 最新の Ubuntu スクリプト]をベースとして使い、あなたのシステムでは不要なモジュールを取り除くという方法を取ることもできます。モジュールを減らすと、ブートプロセスが比較的速くなり、ESP のスペースをいくらか節約できます。

また、セキュリティを高めるために、EFI バイナリに[https://github.com/rhboot/shim/blob/main/SBAT.md Secure Boot Advanced Targeting (SBAT)] ファイル/セクションを含める必要があります (GRUB が UEFI shim ローダから起動される場合)。SBAT ファイル/セクションには、GRUB バイナリに関するメタデータ (バージョン、メンテナ、開発者、上流の URL) が含まれており、特定の GRUB バージョンに脆弱性がある場合、shim がそのバージョンの GRUB のロードをブロックすることが容易になります [https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/#additional][https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2SecureBootBypass2021] (shim の [https://github.com/rhboot/shim/blob/main/SBAT.md UEFI shim bootloader secure boot life-cycle improvements] というドキュメントで説明されています)。

SBAT セクションが {{ic|grubx64.efi}} に無いと、shim は {{ic|grubx64.efi}} の起動に失敗します。

GRUB がインストールされている場合、シンプルな SBAT ''.csv'' ファイルが {{ic|/usr/share/grub/sbat.csv}} で提供されています。

その {{ic|/usr/share/grub/sbat.csv}} ファイルと必要な {{ic|GRUB_MODULES}} を使って GRUB を再インストールし、GRUB バイナリを署名してください:

# grub-install --target=x86_64-efi --efi-directory=''esp'' --modules="${GRUB_MODULES}" --sbat /usr/share/grub/sbat.csv
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/GRUB/grubx64.efi ''esp''/EFI/GRUB/grubx64.efi
# cp ''esp''/EFI/GRUB/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi

再起動し、''MokManager'' で鍵を選択すれば、セキュアブートが機能するはずです。

==== セキュアブートを使用する ====

インストール後は、[[セキュアブート#セキュアブートを実現する]] を見て、セキュアブートを有効化する手順を確認してください。

CA 鍵の方法を取っている場合、鍵の管理や登録、ファイルの署名は {{pkg|sbctl}} で自動化できます。詳細は [[セキュアブート#sbctl でより簡単に行う]] を見てください。

== BIOS システム ==

=== GUID Partition Table (GPT) 特有の手順 ===

BIOS/[[GPT]] の構成では、[https://www.gnu.org/software/grub/manual/grub/html_node/BIOS-installation.html#BIOS-installation BIOS ブートパーティション]が必要です。GRUB は {{ic|core.img}} をこのパーティションに埋め込みます。

{{Note|
* この方法を試す前に、すべてのシステムでこのパーティショニング方式がサポートされているわけではないということを心に留めておいてください。詳細は [[パーティショニング#GUID Partition Table]] を見てください。
* BIOS ブートパーティションは BIOS/GPT のセットアップでのみ GRUB が必要とします。BIOS/MBR セットアップでは、GRUB は MBR の後にある隙間を {{ic|core.img}} のために使用します。しかし、GPT では最初のパーティションの前に未使用の領域があることは保証されていません。
* [[UEFI]] システムでは、ブートセクタが組み込まれないので、BIOS ブートパーティションは必要ありません。しかし、UEFI システムでは依然として [[EFI システムパーティション]]が必要です。
}}

ディスク上にパーティションタイプ GUID {{ic|21686148-6449-6E6F-744E-656564454649}} の、ファイルシステムの無い 1 メビバイト (''fdisk'' や ''gdisk'' で {{ic|1=+1M}}) のパーティションを作成してください。

* [[fdisk]] では、パーティションタイプ {{ic|BIOS boot}} を選択してください。
* [[gdisk]] では、パーティションタイプコード {{ic|ef02}} を選択してください。
* [[parted]] では、そのパーティションで {{ic|bios_grub}} フラグをセット/アクティブ化してください。

このパーティションはどのような順番で配置しても良いですが、ディスクの先頭 2 TiB 以内になければなりません。このパーティションは GRUB のインストール前に作成する必要があります。パーティションの準備が完了したら、以下の指示に従ってブートローダーをインストールします。

GPT のアライメント仕様から外れますが、最初のパーティションの前にあるスペースは BIOS ブートパーティションとしても使用できます。このパーティションは定期的にアクセスされるものではないのでパフォーマンスの問題は無視できますが、一部のディスクユーティリティは警告を発します。''fdisk'' や ''gdisk'' では、セクター 34 から 2047 までの区間の新しいパーティションを作成して、先のパーティションタイプを設定してください。見える状態のパーティションが先頭から始まるようにするには、このパーティションを最後に追加することを検討してください。

=== Master Boot Record (MBR) 特有の手順 ===

通常、MBR でパーティションされた環境において [[MBR]] の後の隙間 (512 バイトの MBR 領域の後ろで最初のパーティションの前) は 31 KiB になっていて、このパーティションテーブルでは DOS 互換のシリンダーアライメントは問題になりません。しかしながら GRUB の {{ic|core.img}} 用に十分な領域を確保するために 1 から 2 MiB ほど MBR の後の領域をとることを推奨します ({{bug|24103}})。この領域を獲得したり他の 512 バイトでないセクターの問題を起こさないために ({{ic|core.img}} の埋め込みとは関係ありません) 1 MiB [[パーティショニング#パーティションアライメント|パーティションアライメント]]をサポートしているパーティションツールを使うのが得策です。

=== インストール ===

{{Pkg|grub}} パッケージを[[インストール]]してください ({{AUR|grub-legacy}} がインストールされている場合は置き換えられます。) 次に以下を実行してください:

# grub-install --target=i386-pc ''/dev/sdX''

{{ic|i386-pc}} は実際のアーキテクチャに関わらず使用されます。{{ic|''/dev/sdX''}} は GRUB がインストールされる '''ディスク''' ('''パーティションではありません''') です。例えば、{{ic|/dev/sda}}、{{ic|/dev/nvme0n1}}、{{ic|/dev/mmcblk0}} です。ブロックデバイスの命名方法については [[デバイスファイル#ブロックデバイスの名前]] を参照してください。

次に、[[#メイン設定ファイルの生成|メイン設定ファイルを生成]]する必要があります。

{{ic|/boot}} に [[LVM]] を使用している場合、GRUB を複数の物理ディスク上にインストールすることができます。

{{Tip|USB メモリなどに GRUB をインストールする他の方法については [[GRUB/ヒントとテクニック#代替インストール方法]] を参照してください。}}

{{ic|grub-install}} コマンドの詳細については、{{man|8|grub-install}} および [https://www.gnu.org/software/grub/manual/grub/html_node/BIOS-installation.html#BIOS-installation GRUB Manual] を参照してください。

== 設定 ==

インストールされたシステムでは、GRUB は起動の度に設定ファイル {{ic|/boot/grub/grub.cfg}} をロードします。ツールを使う場合は、[[#grub.cfg の生成]] を、手動で作成する場合は [[#grub.cfg のカスタマイズ]] を参照してください。

=== grub.cfg の生成 ===

このセクションでは {{ic|/etc/default/grub}} 設定ファイルの編集についてだけ扱っています。他のオプションは [[GRUB/ヒントとテクニック]] を見て下さい。

{{Note|{{ic|/etc/grub.d/}} 下のファイルや {{ic|/etc/default/grub}} に変更を加えた後は必ず[[#メイン設定ファイルの生成|メイン設定ファイルの再生成]]を行なって下さい。}}

{{Warning|GRUB の新しいバージョンで設定ファイルの構文が変更された場合、ブートローダーをアップデート/再インストールしてください ([[#UEFI システム]] や [[#BIOS システム]] を見てください)。設定が一致しないと、システムが起動できなくなる可能性があります。例えば、新しい設定では既存の GRUB バイナリが認識しない関数が使用されているかもしれず、想定外の動作を引き起こす可能性があります。}}

==== メイン設定ファイルの生成 ====

インストールした後は、メインの設定ファイル {{ic|/boot/grub/grub.cfg}} を生成する必要があります。生成プロセスは、{{ic|/etc/default/grub}} 内の様々なオプションや {{ic|/etc/grub.d/}} 下のスクリプトによって制御されます。{{ic|/etc/default/grub}} におけるオプションのリストと、それぞれのオプションの簡潔な説明は、GNU の[https://www.gnu.org/software/grub/manual/grub/html_node/Simple-configuration.html ドキュメント]を参照してください。

追加の設定をしていない場合、設定ファイル自動生成スクリプトは、ブートさせるシステムのルートファイルシステムを判定し、その情報を設定ファイルに保存します。これを成功させるには、システムを起動させているか、またはシステムに chroot していることが重要です。

{{Note|1=<nowiki></nowiki>
* デフォルトのファイルパスは {{ic|/boot/grub/grub.cfg}} です、{{ic|/boot/grub/i386-pc/grub.cfg}} ではありません。
* [[chroot]] や [[systemd-nspawn]] コンテナで ''grub-mkconfig'' を実行しようとした場合、次のようなエラーによりうまく行かないことがあります: {{ic|grub-probe: error: failed to get canonical path of ''/dev/sdaX''}}。この場合、[https://bbs.archlinux.org/viewtopic.php?pid=1225067#p1225067 このフォーラムの投稿]で記述されているように [[arch-chroot]] を使ってみて下さい。
}}

''grub-mkconfig'' ツールを使って {{ic|/boot/grub/grub.cfg}} を生成してください:

# grub-mkconfig -o /boot/grub/grub.cfg

デフォルトで、生成スクリプトは Arch Linux の[[カーネル]]のメニューエントリを自動的に設定に追加します。

{{Tip|
* [[カーネル]]をインストール/アンインストールした後は、上記の ''grub-mkconfig'' コマンドを再度実行する必要があります。
* 複数の GRUB エントリを管理するためのヒントとして、例えば {{Pkg|linux}} と {{Pkg|linux-lts}} の両方を使用している場合、[[GRUB/ヒントとテクニック#複数のエントリ]] を見てください。
}}

他のオペレーティングシステムのエントリを自動的に追加する方法は [[#他の OS の検出]] を見てください。

{{ic|/etc/grub.d/40_custom}} を編集して {{ic|/boot/grub/grub.cfg}} を再生成することで、追加のカスタムメニューエントリを追加することができます。または、{{ic|/boot/grub/custom.cfg}} を作成して、そこにカスタムのメニューエントリを追加することもできます。{{ic|/boot/grub/custom.cfg}} を編集した後に ''grub-mkconfig'' を再度実行する必要はありません。{{ic|/etc/grub.d/41_custom}} は必要な {{ic|source}} 文を設定ファイルに追加するからです。

{{Tip|{{ic|/etc/grub.d/40_custom}} は {{ic|/etc/grub.d/''nn''_custom}} を作成する際のテンプレートとして使うことができます。{{ic|''nn''}} の部分は優先順位で、スクリプトを実行する順番を決定します。スクリプトを実行する順番は GRUB ブートメニューエントリの配置を決定します。必要なスクリプトを確実に実行させるために、{{ic|''nn''}} は {{ic|06}} よりも大きくする必要があります。}}

カスタムのメニューエントリの例は [[#ブートメニューエントリの例]] を見てください。

==== 他の OS の検出 ====

''grub-mkconfig'' で、インストールされている他のシステムを検索して自動的にメニューに追加するには、 {{Pkg|os-prober}} パッケージを [[インストール]] して、他のシステムが起動するパーティションを[[マウント]]してください。その後、''grub-mkconfig'' を再実行します。もし、{{ic|Warning: os-prober will not be executed to detect other bootable partitions}} と出力されたら、{{ic|/etc/default/grub}} を編集して次の行を追加/アンコメントしてください:

GRUB_DISABLE_OS_PROBER=false

その後、もう一度試してください。

{{Note|
* 正確なマウントポイントは重要ではありません。''os-prober'' は {{ic|mtab}} を読み込んで、起動可能なエントリを検索すべき場所を特定します。
* 他のオペレーティングシステムをエントリに含めるために、''grub-mkconfig'' を実行するたびに対象のパーティションをマウントすることを忘れないでください。
* ''os-prober'' は、chroot 内で実行すると正しく動作しないかもしれません。そのような場合は、再起動してシステムに入り、再び試してください。
}}

{{Tip|最後に選択したブートエントリを GRUB に記憶させたい場合もあるでしょう、[[GRUB/ヒントとテクニック#以前のエントリを思い出させる]] を参照してください。}}

===== Windows =====

UEFI モードでインストールされた Windows の場合、Windows Boot Manager ({{ic|bootmgfw.efi}}) を含んでいる [[EFI システムパーティション]]がマウントされていることを確認してください。root として {{ic|os-prober}} を実行すると、Windows のエントリを検出・生成します。

BIOS モードでインストールされた Windows の場合、Windows ''システムパーティション'' をマウントしてください (そのパーティションの[[永続的なブロックデバイスの命名#by-label|ファイルシステムラベル]]は {{ic|System Reserved}} ({{ic|システムで予約済み}}) か {{ic|SYSTEM}} であるはずです)。root として {{ic|os-prober}} を実行すると、Windows のエントリを検出・生成します。

{{Note|BIOS モードでインストールされた Windows の場合:
* NTFS パーティションはデフォルトの Linux ドライバでマウントすると、必ずしも検出されないかもしれません。GRUB が検出しない場合、[[NTFS-3G]] をインストールして再マウントしてみてください。
{{Out of date| Windows 7 以降、{{ic|bootmgr}} は[[Wikipedia:System partition and boot partition#Microsoft definition|システムパーティション]]内にあり、このパーティションは暗号化されていません。}}
* 暗号化された Windows パーティションは、マウントする前に暗号化を解除する必要があるかもしれません。BitLocker では、[[cryptsetup]] や {{AUR|dislocker}} で実行できます。これで {{Pkg|os-prober}} が正しいエントリを追加できるはずです。
}}

==== 追加引数 ====

カスタムの追加引数を Linux イメージに渡すために、{{ic|/etc/default/grub}} で {{ic|GRUB_CMDLINE_LINUX}} と {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} 変数を設定することができます。これら2つは互いに追加され、標準のブートエントリを作成する際にカーネルに渡されます。''recovery'' ブートエントリについては、{{ic|GRUB_CMDLINE_LINUX}} だけが生成時に使われます。

両方を使う必要はありませんが、上手く使えば便利です。例えば、{{ic|1=GRUB_CMDLINE_LINUX_DEFAULT="resume=UUID=''uuid-of-swap-partition'' quiet"}} ({{ic|''uuid-of-swap-partition''}} は [[ハイバネート]]後に復帰できるようにするためのスワップパーティションの [[UUID]])。この例の設定では、(ハイバネートからの) 復帰をせず、メニューエントリからの起動中にカーネルメッセージを非表示にする {{ic|quiet}} も無いリカバリブートエントリを生成します。しかし、他の (標準の) メニューエントリはこれらのオプションを持ちます。

デフォルトでは、''grub-mkconfig'' はルートファイルシステムの [[UUID]] を検出して、設定にそれを反映します。これを無効化するには、{{ic|1=GRUB_DISABLE_LINUX_UUID=true}} をアンコメントしてください。

GRUB リカバリエントリを生成するには、{{ic|/etc/default/grub}} 内の {{ic|GRUB_DISABLE_RECOVERY}} が {{ic|true}} に設定されていない必要があります。

詳細は [[カーネルパラメータ]] を参照してください。

==== トップレベルのメニューエントリを設定する ====

デフォルトでは、''grub-mkconfig'' は、含まれているカーネルを {{ic|sort -V}} を使ってソートし、それらの中の最初のカーネルをトップレベルのエントリとして使用します。すなわち、例えば {{ic|/boot/vmlinuz-linux-lts}} は {{ic|/boot/vmlinuz-linux}} より前に来るので、{{Pkg|linux-lts}} と {{Pkg|linux}} の両方がインストールされている場合、LTS カーネルがトップレベルのメニューエントリとなります。これは、望ましくない場合があるでしょう。この挙動は、{{ic|/etc/default/grub}} 内の {{ic|1=GRUB_TOP_LEVEL=''path_to_kernel''"}} を指定することでオーバーライドすることができます。例えば、標準のカーネルをトップレベルのメニューエントリにするには、{{ic|1=GRUB_TOP_LEVEL="/boot/vmlinuz-linux"}} を使用します。

==== LVM ====

{{Warning|GRUB はシンプロビジョニングされた論理ボリュームをサポートしていません。}}

{{ic|/boot}} や {{ic|/}} に [[LVM]] を使用している場合、{{ic|lvm}} モジュールをプリロードするようにしてください:

{{hc|/etc/default/grub|2=
GRUB_PRELOAD_MODULES="... lvm"
}}

==== RAID ====

GRUB は [[RAID]] ボリュームの便利な管理手段を提供します。ボリュームをネイティブに管理できるようにするために、GRUB モジュール {{ic|mdraid09}} か {{ic|mdraid1x}} をロードする必要があります:

{{hc|/etc/default/grub|2=
GRUB_PRELOAD_MODULES="... mdraid09 mdraid1x"
}}

例えば、{{ic|/dev/md0}} は以下のようになります:

set root=(md/0)

パーティショニングされた RAID ボリューム (例: {{ic|/dev/md0p1}}) は以下のようになります:

set root=(md/0,1)

{{ic|/boot}} パーティションに RAID1 を使用している場合 (あるいは、{{ic|/boot}} が RAID1 ルートパーティション上に存在する場合) に GRUB をインストールするには、BIOS システム上では、両方のドライブ上で ''grub-install'' を実行してください。例:

# grub-install --target=i386-pc --debug /dev/sda
# grub-install --target=i386-pc --debug /dev/sdb

ここでは、{{ic|/boot}} が存在する RAID1 アレイが、{{ic|/dev/sda}} と {{ic|/dev/sdb}} に存在するとしています。

{{Note|GRUB は [[Btrfs]] RAID 0/1/10 からの起動をサポートしていますが、RAID 5/6 はサポートしていません。RAID 5/6 に対しては [[mdadm]] を使用することができます (mdadm は GRUB によってサポートされています)。

==== 暗号化された /boot ====

GRUB には暗号化された {{ic|/boot}} を起動するための特別なサポートがあります。これは、[[LUKS]] ブロックデバイスをアンロックして、GRUB の設定を読み込み、[[initramfs]] と [[カーネル]] をそのブロックデバイスからロードすることにより行われます。このオプションは[[dm-crypt/特記事項#暗号化されていない boot パーティションのセキュア化|暗号化されていないブートパーティション]]の問題を解決することを試みます。

{{Tip|{{ic|/boot}} を別のパーティションに保存する必要は'''ありません'''。システムのルート {{ic|/}} ディレクトリツリー下に保存することもできます。}}

{{Warning|GRUB 2.12rc1 の LUKS2 に対するサポートは限られています。詳細は [[#LUKS2]] セクションを見てください。}}

この機能を有効化するには、{{ic|/boot}} が存在するパーティションを通常通り [[LUKS]] を使って暗号化してください。そして、以下のオプションを {{ic|/etc/default/grub}} に追加してください。

{{hc|/etc/default/grub|output=
GRUB_ENABLE_CRYPTODISK=y
}}

このオプションは grub-install により使用され、grub の {{ic|core.img}} を生成します。

このオプションを追加した後やパーティションを暗号化した後に [[#インストール|GRUB を(再)インストール]]することを忘れないでください。

これだけだと、パスフレーズを2回入力させられることになります。1回目は起動の初期段階で GRUB が {{ic|/boot}} マウントポイントをアンロックするためのもので、2回目は iniramfs により実装されている root ファイルシステムそれ自体をアンロックするためのものです。[[dm-crypt/デバイスの暗号化#キーファイルを initramfs に埋め込む|キーファイル]]を使えば、これを防げます。

{{Warning|
* [[#メイン設定ファイルの生成|メインの設定ファイルを生成]]したいときは、{{ic|/boot}} がマウントされていることを確認してください。
* {{ic|/boot}} マウントポイントが関与するシステムアップデートを行うために、アップデートする前に、暗号化された {{ic|/boot}} がアンロックされていて、かつ、マウントされていることを確認してください。{{ic|/boot}} パーティションが別にある場合、[[crypttab]] を[[dm-crypt/デバイスの暗号化#キーファイルを initramfs に埋め込む|キーファイル]]と一緒に使うことでこれを自動化できます。
}}

{{Note|
* 特殊なキーマップを使用している場合、デフォルトの GRUB 環境にはそのようなキーマップが存在しません。このことは、[[LUKS]] ブロックデバイスをアンロックするためにどのようにしてパスフレーズを入力するかに関連しています。[[GRUB/ヒントとテクニック#初期ブートにおけるコアイメージの手動設定]] を参照してください。
* パスワードの入力画面が表示されない問題が発生した場合 (cryptouuid や cryptodisk、"device not found" に関係するエラー)、{{ic|1=--modules="part_gpt part_msdos"}} を {{ic|grub-install}} コマンドの最後に付け加えて GRUB を再インストールしてみてください。
}}

{{Tip|1=[https://bbs.archlinux.org/viewtopic.php?id=234607 pacman フック] を使用すれば、{{ic|/boot}} 内のファイルにアクセスする必要のあるアップグレード時に {{ic|/boot}} を自動マウントできます。}}

===== LUKS2 =====
{{Out of date|1=Grub 2.14rc1はArgon2iとArgon2id PBKDFsをサポートします。 [https://cgit.git.savannah.gnu.org/cgit/grub.git/commit/?id=6052fc2cf684dffa507a9d81f9f8b4cbe170e6b6 アップストリームのコミットを参照。]|2=:en:Talk:GRUB#grub_2:2.14rc1_added_support_for_LUKS2_+_argon2_encryption.}}

[[#インストール]] 章で説明されているように、{{ic|grub-install}} を使用して LUKS サポートありでブータブルな GRUB イメージを作成してください。ただし、いくつかの注意点があります:

* LUKS2 の初期サポートが GRUB 2.06 で追加されましたが、いくつかの制限があります。これらの制限は、GRUB 2.12rc1 で部分的にのみ対処されています。[https://savannah.gnu.org/bugs/?55093 GRUB bug #55093] を参照してください。
* GRUB 2.12rc1 から、{{ic|grub-install}} で LUKS2 のロックを解除するためのコアイメージを作成できるようになりました。しかし、PBKDF2 のみがサポートされており、Argon2 はサポートされていません。
* Argon2id (''cryptsetup'' デフォルト) と Argon2i PBKDF はサポートされていません ([https://savannah.gnu.org/bugs/?59409 GRUB bug #59409])。PBKDF2 のみのサポートです。

:{{Tip|LUKS2 と Argon のサポートパッチが施された {{AUR|grub-improved-luks2-git}} を使用できます。このパッケージの Argon サポートには UEFI システムが必要であることに注意してください。[https://aur.archlinux.org/packages/grub-improved-luks2-git#comment-911119]}}

{{Note|GRUB 2.12rc1 より前では、カスタムの GRUB 設定ファイルを使って {{ic|grub-mkimage}} コマンドで EFI バイナリを手動で作成する必要がありました。(例えば、{{ic|/boot/grub/grub-pre.cfg}} に {{ic|cryptomount}}、{{ic|insmod normal}}、そして {{ic|normal}} への呼び出しを追加する必要がありました。) しかし、これはもはや必要なくなり、{{ic|grub-install}} だけで十分です。ただし、2.06 からアップグレードした後に少なくとも一回は {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} を実行する必要があります。}}

起動中に無効なパスフレーズを入力して GRUB のレスキューシェルに入った場合、{{ic|cryptomount -a}} を実行してすべての (できれば1つだけ) 暗号化されたパーティションをマウントしてみてください。または、{{ic|cryptomount -u $crypto_uuid}} を使用して特定のパーティションをマウントしてください。その後、通常通り {{ic|insmod normal}} と {{ic|normal}} で進めてください。

正しいパスフレーズを入力したが {{ic|Invalid passphrase}} というエラーにより即座に戻される場合、正しい暗号化モジュールを指定していることを確認してください。{{ic|cryptsetup luksDump ''/dev/nvme0n1p2''}} を使って、ハッシュ関数 (SHA-256, SHA-512) とインストールされているモジュール ({{ic|gcry_sha256}}, {{ic|gcry_sha512}}) が一致するか、PBKDF アルゴリズムが pbkdf2 であるかを確認してください。{{ic|cryptsetup luksConvertKey --hash ''sha256'' --pbkdf pbkdf2 ''/dev/nvme0n1p2''}} を使えば、ハッシュと PBDKDF アルゴリズムを今あるキーに対して変更することができます。通常の状況では、パスフレーズが処理されるのに数秒掛かるはずです。

=== grub.cfg のカスタマイズ ===

このセクションでは ''grub-mkconfig'' に頼らずに {{ic|/boot/grub/grub.cfg}} 内にある GRUB のブートエントリーを手動で作成する方法について言及します。

基本的な GRUB の設定ファイルでは以下のオプションが使用されます。

* {{ic|(hd''X'',''Y'')}} はディスク ''X'' 上に存在するパーティション ''Y'' を表します。パーティション番号は 1 から始まり、ディスク番号は 0 から始まります。
* {{ic|1=set default=''N''}} は、ユーザーが操作せずにタイムアウトした後に選択されるデフォルトのブートエントリを表します。
* {{ic|1=set timeout=''M''}} は、ユーザーの選択が無かった場合に ''M'' 秒の間待ってデフォルトのブートエントリが起動されることを表します。
* {{ic|<nowiki>menuentry "title" {entry options}</nowiki>}} は {{ic|title}} というタイトルのブートエントリを表します。
* {{ic|1=set root=(hd''X'',''Y'')}} はカーネルと GRUB モジュールが格納されているブートパーティションを表します。(boot は分離されたパーティションである必要はなく、単に "root" パーティション ({{ic|/}}) 下にあるディレクトリを指定しても構いません)

==== LoaderDevicePartUUID ====

{{man|8|systemd-gpt-auto-generator}} が [[systemd#GPT パーティションの自動マウント|GPT パーティションの自動マウント]]をするために必要な {{ic|LoaderDevicePartUUID}} UEFI 変数を GRUB で設定するには、{{ic|grub.cfg}} で {{ic|bli}} モジュールをロードしてください:

{{bc|1=
if [ "$grub_platform" = "efi" ]; then
insmod bli
fi
}}

==== ブートメニューエントリの例 ====

{{Tip|以下のブートエントリは ''grub-mkconfig'' によって生成された {{ic|/boot/grub/grub.cfg}} でも使用可能です。以下を {{ic|/etc/grub.d/40_custom}} に追加して[[#メイン設定ファイルの生成|メインの設定ファイルを再生成]]するか、あるいは以下を直接 {{ic|/boot/grub/custom.cfg}} に追加してください。}}

複数の GRUB エントリーを管理するヒントとして、例えば {{Pkg|linux}} と {{Pkg|linux-lts}} カーネルを同時使用している場合は [[GRUB/ヒントとテクニック#複数のエントリ]] を見てください。

[[Archiso]] と [https://archboot.com Archboot] のブートメニューエントリについては [[マルチブート USB ドライブ#ブートエントリ]] を見てください。

===== GRUB コマンド =====

====== "Shutdown" メニューエントリ ======

{{bc|
menuentry "System shutdown" {
echo "System shutting down..."
halt
}
}}

====== "Restart" メニューエントリ ======

{{bc|
menuentry "System restart" {
echo "System rebooting..."
reboot
}
}}

====== "UEFI Firmware Settings" メニューエントリ ======

{{bc|1=
if [ ${grub_platform} == "efi" ]; then
menuentry 'UEFI Firmware Settings' --id 'uefi-firmware' {
fwsetup
}
fi
}}

===== EFI バイナリ =====

UEFI モードで起動している場合、GRUB は他の EFI バイナリをチェインロードできます。

{{Tip|1=GRUB が UEFI モードで起動している時にだけメニューエントリを表示するには、メニューエントリを {{ic|if}} 文で囲ってください:

{{bc|1=
if [ ${grub_platform} == "efi" ]; then
''UEFI のときだけ表示するメニューエントリをここへ''
fi
}}

}}

====== UEFI シェル ======

[[EFI システムパーティション]]直下に [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]] を置いてメニューエントリに追加すれば、UEFI シェルを起動できます:

{{bc|1=
menuentry "UEFI Shell" {
insmod fat
insmod chain
search --no-floppy --set=root --file /shellx64.efi
chainloader /shellx64.efi
}
}}

====== gdisk ======

[[gdisk#gdisk EFI アプリケーション|gdisk EFI アプリケーション]]をダウンロードして {{ic|gdisk_x64.efi}} を {{ic|''esp''/EFI/tools/}} にコピーしてください。

{{bc|1=
menuentry "gdisk" {
insmod fat
insmod chain
search --no-floppy --set=root --file /EFI/tools/gdisk_x64.efi
chainloader /EFI/tools/gdisk_x64.efi
}
}}

====== ユニファイドカーネルイメージをチェインロード ======

[[セキュアブート]]に従って生成したか他の方法によって生成した [[Unified カーネルイメージ]]を持っているならば、それをブートメニューに追加できます。例えば:

{{bc|1=
menuentry "Arch Linux" {
insmod fat
insmod chain
search --no-floppy --set=root --fs-uuid ''FILESYSTEM_UUID''
chainloader /EFI/Linux/arch-linux.efi
}
}}

===== デュアルブート =====

====== GNU/Linux ======

もう一つのディストリビューションが {{ic|sda2}} パーティションにあると仮定します:

{{bc|1=
menuentry "Other Linux" {
set root=(hd0,2)
linux /boot/vmlinuz (必要であれば追加のオプションをここへ)
initrd /boot/initrd.img (カーネルが必要とする/使用するイメージはここへ)
}
}}

代わりに UUID やファイルシステムのラベルで GRUB に正しいパーティションを探させるには:

{{bc|1=
menuentry "Other Linux" {
# UUID が 763A-9CB6 だとすると
search --no-floppy --set=root --fs-uuid 763A-9CB6

# OTHER_LINUX というラベルで探す (パーティションラベルが曖昧でないことを確認してください)
#search --no-floppy --set=root --label OTHER_LINUX

linux /boot/vmlinuz (必要であれば追加のオプションをここへ。例えば、root=UUID=763A-9CB6)
initrd /boot/initrd.img (カーネルが必要とする/使用するイメージはここへ)
}
}}

もう一つのディストリビューションが、インストール済みの GRUB と {{ic|grub.cfg}}、カーネル、initramfs のある有効な {{ic|/boot}} フォルダーをすでに持っているならば、GRUB にその {{ic|grub.cfg}} ファイルを起動中にその場で読み込ませることができます。例えば、{{ic|hd0}} と4番目の GPT パーティションの場合:

{{bc|1=
menuentry "configfile hd0,gpt4" {
insmod part_gpt
insmod btrfs
insmod ext2
set root='hd0,gpt4'
configfile /boot/grub/grub.cfg
}
}}

このエントリを選ぶと GRUB は他のボリュームからその {{ic|grub.cfg}} を読み込み、メニューを表示させます。{{ic|configfile}} ファイル内のコマンドによって環境変数が変更されても、{{ic|configfile}} から返ると環境変数の変更はすべて破棄されます。始めの GRUB メニューに戻る場合は {{ic|Esc}} を押してください。

====== UEFI/GPT モードでインストールされた Windows ======

このモードではメニューエントリが選択されると Windows ブートローダーの場所を発見し、GRUB のあとにブートローダーをチェインロードします。ここでするべきことは主に Windows の [[EFI システムパーティション]]を見つけて、そのパーティションから Windows のブートローダーを実行することです。

{{Note|このメニューエントリは、UEFI ブートモードで実行中であり、かつ Windows のビット数が UEFI のビット数と一致する場合にのみ機能します。BIOS モードでインストールされた GRUB では機能しません。さらなる情報については [[Windows と Arch のデュアルブート#Windows の UEFI と BIOS の制限]]と [[Windows と Arch のデュアルブート#ブートローダーの UEFI と BIOS の制限]] をご覧ください。}}

{{bc|1=
if [ "${grub_platform}" == "efi" ]; then
menuentry "Microsoft Windows Vista/7/8/8.1 UEFI/GPT" {
insmod part_gpt
insmod fat
insmod chain
search --no-floppy --fs-uuid --set=root $hints_string $fs_uuid
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
fi
}}

{{ic|$hints_string}} と {{ic|$fs_uuid}} は以下の2つのコマンドで得られます。

{{ic|$fs_uuid}} コマンドは EFI システムパーティションの UUID を割り出します。

{{hc|1=# grub-probe --target=fs_uuid ''esp''/EFI/Microsoft/Boot/bootmgfw.efi|2=
1ce5-7f28
}}

代わりに、{{ic|lsblk --fs}} を実行して、EFI システムパーティションの UUID をそこから読み込むこともできます。

{{ic|$hints_string}} コマンドは EFI システムパーティションの場所を割り出します。以下の例ではハードドライブ0にあります:

{{hc|1=# grub-probe --target=hints_string ''esp''/EFI/Microsoft/Boot/bootmgfw.efi|2=
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1
}}

以上の2つのコマンドでは Windows が使用する ESP が {{ic|''esp''}} にマウントされていると仮定しています。Windows である以上、Windows の EFI ファイルへのパスが異なる場合があるかもしれません。

====== BIOS/MBR モードでインストールされた Windows ======

{{Note|GRUB は {{ic|bootmgr}} ディレクトリの直接ブートをサポートしています。Windows を BIOS/MBR で起動するためにパーティションブートセクターを [https://www.gnu.org/software/grub/manual/grub.html#Chain_002dloading チェインロード]する必要はもはやありません。}}

{{Warning|{{ic|/bootmgr}} が存在する場所は '''システムパーティション''' であり、"本当"の Windows パーティション (通常、{{ic|C:}}) ではありません。システムパーティションの[[永続的なブロックデバイスの命名#by-label|ファイルシステムラベル]]は {{ic|System Reserved}} ({{ic|システムで予約済み}}) か {{ic|SYSTEM}} であり、サイズは約100~549 MiB 程度です。さらなる情報については [[Wikipedia:System partition and boot partition]] をご覧ください。}}

このセクションを通して Windows のパーティションは {{ic|/dev/sda1}} にあると仮定します。パーティションが異なる場合は {{ic|hd0,msdos1}} という記述をすべて変更してください。

{{Note|以下のメニューエントリは BIOS ブートモードでのみ機能します。UEFI モードでインストールされた GRUB では機能しません。[[Windows と Arch のデュアルブート#Windows の UEFI と BIOS の制限]] と [[Windows と Arch のデュアルブート#ブートローダーの UEFI と BIOS の制限]] をご覧ください。}}

両方の例で {{ic|''XXXX-XXXX''}} はファイルシステムの UUID を表しています。UUID は {{ic|lsblk --fs}} コマンドを使って得られます。実際の UUID に置き換えてください。

Windows Vista/7/8/8.1/10 では:

{{bc|1=
if [ "${grub_platform}" == "pc" ]; then
menuentry "Microsoft Windows Vista/7/8/8.1/10 BIOS/MBR" {
insmod part_msdos
insmod ntfs
insmod ntldr
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 ''XXXX-XXXX''
ntldr /bootmgr
}
fi
}}

Windows XP では:

{{bc|1=
if [ "${grub_platform}" == "pc" ]; then
menuentry "Microsoft Windows XP" {
insmod part_msdos
insmod ntfs
insmod ntldr
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 ''XXXX-XXXX''
ntldr /ntldr
}
fi
}}

{{Note|GRUB をインストールすると Windows 8 が汚染される場合があります。この場合、{{ic|\boot\bcd}} (エラーコード {{ic|0xc000000f}})のエラーにより Windows が起動できなくなります。これを直すには Windows 回復コンソール(インストールディスク上にある {{ic|cmd.exe}})を開いて、以下を実行してください:

X:\> bootrec.exe /fixboot
X:\> bootrec.exe /RebuildBcd

{{ic|bootrec.exe /Fixmbr}} を'''実行しない'''でください。GRUB が吹き飛びます。
あるいは、トラブルシューティングメニューにあるスタートアップ修復機能を使用できます。これは GRUB を吹き飛ばしませんし、ほとんどのエラーを修復します。
また、対象のハードドライブとブート可能ドライブの両方'''だけ'''を接続しておくほうが良いでしょう。通常、他のデバイスが接続されていると Windows はブート情報の修復に失敗します。
}}

===== ラベルを使う =====

{{ic|search}} コマンドに対して {{ic|--label}} オプションを使えば、ファイルシステムに付けられた人間が読みやすい文字列であるラベルを使うことができます。まずはじめに、[[永続的なブロックデバイスの命名#by-label|ファイルシステムにラベルがあることを確認]]してください。

そして、ラベルを使ってエントリを追加してください。例えば:

menuentry "Arch Linux, session texte" {
search --label --set=root archroot
linux /boot/vmlinuz-linux root=/dev/disk/by-label/archroot ro
initrd /boot/initramfs-linux.img
}

== コマンドシェルを使う ==

GRUB のモジュールを全て保存するには MBR は小さすぎるので、メニューと基本的なコマンドだけが MBR に入っています。GRUB の機能のほとんどは {{ic|/boot/grub}} 内のモジュールとして存在し、必要に応じて挿入されます。エラー状態になると (例: パーティションレイアウトが変更された場合)、GRUB が起動に失敗する場合があります。このとき、コマンドシェルが表示されます。

GRUB は複数のシェル/プロンプトを提供しています。メニューの読込に問題があってもブートローダがディスクを見つけられるときは、おそらく "normal" シェルに落とされるでしょう:

grub>

さらに深刻な問題 (例: GRUB が必要なファイルを見つけられないなど) があるときは、代わりに "rescue" シェルに落とされるでしょう:

grub rescue>

rescue シェルは通常のシェルの制限されたサブセットで、使える機能が非常に少なくなっています。rescue シェルが出てきた時は、まず "normal" モジュールの挿入を試して、"normal" シェルを起動してみて下さい:

grub rescue> set prefix=(hdX,Y)/boot/grub
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod
rescue:grub> normal

=== ページャのサポート ===

GRUB はページャをサポートしており長い出力をするコマンド ({{ic|help}} コマンドなど) を読むことができます。これは通常のシェルモードでしか動作せずレスキューモードでは使えません。ページャを有効にするには、GRUB コマンドシェルで次を入力して下さい:

sh:grub> set pager=1

=== コマンドシェル環境を使ってオペレーティングシステムを起動する ===

grub>

GRUB のコマンドシェル環境を使ってオペレーティングシステムを起動することが可能です。
通常は'''チェインロード'''を使ってドライブやパーティションから Windows / Linux を起動するということが考えられます。

''チェインロード''は現在のブートローダから別のブートローダをロードすることを意味します。

他のブートローダーは、パーティショニングされたディスク (MBR) の先頭や、パーティションレスディスク (VBR) のパーティションの先頭に組み込んだり、あるいは UEFI の場合は EFI バイナリとして組み込むことができます。

==== パーティションの VBR をチェインロード ====

set root=(hdX,Y)
chainloader +1
boot

X=0,1,2...
Y=1,2,3...

例えば最初のハードディスクの最初のパーティションに保存された Windows をチェインロードするには:

set root=(hd0,1)
chainloader +1
boot

同じようにパーティションにインストールされた GRUB をチェインロードすることもできます。

==== ディスクの MBR やパーティションレスディスクの VBR をチェインロード ====

set root=hdX
chainloader +1
boot

==== UEFI モードでインストールされた Windows/Linux のチェインロード ====

insmod fat
set root=(hd0,gpt4)
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi
boot

{{ic|insmod fat}} は、EFI システムパーティション上の Windows ブートローダーにアクセするために、FAT ファイルシステムモジュールをロードするために使用されます。
{{ic|(hd0,gpt4)}} (すなわち {{ic|/dev/sda4}}) は、この例における EFI システムパーティションです。
{{ic|chainloader}} 行のエントリは、チェインロードすべき ''.efi'' ファイルへのパスを指定しています。

==== 通常のロード ====

[[#rescue コンソールを使う]] の例を見て下さい。

=== rescue コンソールを使う ===

まず [[#コマンドシェルを使う]] を見て下さい。標準シェルを有効にできない場合、ライブ CD や他のレスキューディスクを使って起動し、設定のエラーを直して GRUB を再インストールという方法があります。ただし、そのようなブートディスクはいつも使えるというわけではありません (もしくは必要ありません); レスキューコンソールは驚くほど堅牢です。

GRUB rescue で利用できるコマンドには {{ic|insmod}}、{{ic|ls}}、{{ic|set}}、{{ic|unset}} があります。この例では {{ic|set}} と {{ic|insmod}} を使います。{{ic|set}} は変数を変更し {{ic|insmod}} は新しいモジュールを挿入して機能を追加します。

始める前に、ユーザーは自分の {{ic|/boot}} パーティションの位置を知っていなければなりません (分割パーティションなのか、root 下のサブディレクトリなのか):

grub rescue> set prefix=(hd''X'',''Y'')/boot/grub

{{ic|''X''}} は物理ドライブ番号、{{ic|''Y''}} はパーティション番号に置き換えてください。

{{Note|boot パーティションを分割している場合、パスから {{ic|/boot}} を省いて下さい (つまり、{{ic|1=set prefix=(hd''X'',''Y'')/grub}} と入力する)。}}

コンソールの機能を拡張するために、{{ic|linux}} モジュールを挿入します:

grub rescue> insmod i386-pc/linux.mod

もしくは、単純に:

grub rescue> insmod linux

これで、より親しみのあるであろう {{ic|linux}} と {{ic|initrd}} のコマンドが使えます。

例えば、Arch Linux を起動する場合:

set root=(hd0,5)
linux /boot/vmlinuz-linux root=/dev/sda5
initrd /boot/initramfs-linux.img
boot

boot パーティションを分割している (例えば、UEFI を使用している場合など) なら、行を適宜変更する必要があります:

{{Note|boot は別のパーティションであり、ルートパーティションの一部ではないので、上の prefix 変数と同じような形式で boot パーティションを手動で指定する必要があります。}}

set root=(hd0,5)
linux (hd''X'',''Y'')/vmlinuz-linux root=/dev/sda6
initrd (hd''X'',''Y'')/initramfs-linux.img
boot

{{Note|{{ic|linux}} コマンドの実行中に {{ic|error: premature end of file /YOUR_KERNEL_NAME}} と表示される場合は、代わりに {{ic|linux16}} を使ってみて下さい。}}

Arch Linux 環境のブートに成功したら、必要に応じて {{ic|grub.cfg}} を修正し GRUB を再インストールすることができます。

GRUB を再インストールして問題を完全に修正するには、必要応じて {{ic|/dev/sda}} を変更してください。詳しくは [[#インストール]] を見て下さい。

== GRUB を消去 ==

=== UEFI システム ===

''grub'' を削除する前に、他のブートローダがインストールされていて、GRUB の後を引き継ぐように設定されていることを確認してください。

{{hc|$ efibootmgr|
BootOrder: 0003,0001,0000,0002
Boot0000* Windows Boot Manager HD(2,GPT,4dabbedf-191b-4432-bc09-8bcbd1d7dabf,0x109000,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)
Boot0001* GRUB HD(2,GPT,4dabbedf-191b-4432-bc09-8bcbd1d7dabf,0x109000,0x32000)/File(\EFI\GRUB\grubx64.efi)
Boot0002* Linux-Firmware-Updater HD(2,GPT,5dabbedf-191b-4432-bc09-8bcbd1d7dabf,0x109000,0x32000)/File(\EFI\arch\fwupdx64.efi)
Boot0003* Linux Boot Manager HD(2,GPT,4dabbedf-191b-4432-bc09-8bcbd1d7dabf,0x109000,0x32000)/File(\EFI\systemd\systemd-bootx64.efi)
}}

{{ic|BootOrder}} で ''grub'' が最初のエントリになっている場合、[[systemd-boot]] などの他のブートローダをインストールして最初のエントリにしてください。その後、''bootnum'' を使って ''grub'' を削除することができます。

# efibootmgr --delete-bootnum -b 1

また、{{ic|''esp''/EFI/grub}} と {{ic|/boot/grub}} ディレクトリも削除してください。

=== BIOS システム ===

''grub'' を他の BIOS ブートローダに置き換えるには、単に新しいブートローダをインストールしてください (そうすることで、[[パーティショニング#Master Boot Record (bootstrap code)|MBR ブートコード]]が上書きされます)。

{{ic|grub-install}} は {{ic|/boot/grub}} ディレクトリを作成するので、これは手動で削除する必要があります。しかし、''grub'' をまたインストールするかもしれない場合は、このディレクトリを残しておいたほうが良いかもしれません。

UEFI/GPT に移行した後は、[[dd#ブートローダーの削除|dd を使って MBR ブートコードを削除する]]ことができます。

== トラブルシューティング ==

=== サポートのないファイルシステム ===

GRUB が root のファイルシステムをサポートしていない場合、代替の {{ic|/boot}} パーティションをサポートのあるファイルシステムで作成する必要があります。開発バージョンの GRUB である {{aur|grub-git}} が該当するファイルシステムをネイティブサポートしている場合があります。

サポートされないファイルシステムで GRUB を使用した場合、ドライブの [[UUID]] を抽出できないため、GRUB は古典的で非永続的な {{ic|/dev/''sdXx''}} 名を使います。この場合、{{ic|/boot/grub/grub.cfg}} を手動で編集し、{{ic|1=root=/dev/''sdXx''}} を {{ic|1=root=UUID=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX''}} のように置き換える必要があるかもしれません。{{ic|blkid}} コマンドを使えばデバイスの UUID を得られます。[[永続的なブロックデバイスの命名]] を見てください。

GRUB はバージョン 2.0.4 より [[F2FS]] をサポートしていますが、{{ic|extra_attr}} フラグを有効にして作成された F2FS パーティションからブートファイルを正しく読み込むことができません。

=== デバッグメッセージを有効にする ===

{{Note|この変更は[[#メイン設定ファイルの生成|メインの設定ファイルを生成]]すると上書きされます。}}

以下を {{ic|grub.cfg}} に追加してください:

set pager=1
set debug=all

=== msdos-style エラーメッセージ ===

grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding will not be possible!
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.
However, blocklists are UNRELIABLE and its use is discouraged.
grub-setup: error: If you really want blocklists, use --force.

このエラーは VMware コンテナに GRUB をインストールしようとすると起こることがあります。詳しくは [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 ここ] を読んで下さい。最初のパーティションが MBR (ブロック 63) のすぐ後ろから始まっていて、最初のパーティションの前に通常の 1 MiB のスペース (2048 ブロック) がない場合に起こります。[[#Master Boot Record (MBR) 特有の手順]] を読んで下さい。

=== UEFI ===

==== よくあるインストール時のエラー ====

* 一部の UEFI デバイスで起こりうるエラーは、{{ic|Could not prepare Boot variable: Read-only file system}} です。{{ic|/sys/firmware/efi/efivars}} を読み書き可能な状態で再マウントする必要があります。{{bc|# mount -o remount,rw,nosuid,nodev,noexec --types efivarfs efivarfs /sys/firmware/efi/efivars}} [[ブートローダー]]のインストールに関しては [[Gentoo:Handbook:AMD64/Installation/Bootloader#Install|Gentoo Wiki]] を見てください。
* ''sysfs'' か ''procfs'' がある状態で ''grub-install'' を実行すると問題が発生し、{{ic|modprobe efivarfs}} を実行しなければならないと言われる場合、[[Unified Extensible Firmware Interface#efivarfs のマウント|efivarfs をマウント]]して上記のコマンドを実行してみてください。
* {{ic|--target}} と {{ic|--directory}} オプションのどちらかがないと、{{ic|grub-install}} はどこにファームウェアをインストールすればいいのか決められません。そのような場合 {{ic|grub-install}} は {{ic|source_dir does not exist. Please specify --target or --directory}} というメッセージを表示します。
* grub-install の実行後に {{ic|error: ''esp'' doesn't look like an EFI partition}} と表示される場合、おそらくパーティションが [[FAT32]] でフォーマットされていません。

==== ファームウェアブートマネージャーに GRUB エントリを作成する ====

{{ic|grub-install}} は自動的にブートマネージャーにメニューエントリを追加しようと試みます。もし GRUB がそれを行わない場合、[[UEFI#efibootmgr]] を見て、{{ic|efibootmgr}} を使ってメニューエントリを作成する指示を読んでください。しかし、[[UEFI#ISO から UEFI ブータブル USB を作成する]] にあるように、よくある原因は CD/USB を UEFI モードで起動していないというものです。

GRUB エントリをファームウェアブートマネージャに作成する例として、{{ic|efibootmgr -c}} を考えてみましょう。これは、{{ic|/dev/sda1}} が EFI システムパーティションであり、{{ic|/boot/efi}} にマウントされていると仮定します。これは {{ic|efibootmgr}} のデフォルトの挙動です。このツールは、("Linux" という名前の) 新しいブートオプションを作成し、それをブート順序リストの1番目に配置します。オプションを渡すことでデフォルトの挙動を変更できます。デフォルトの OS ローダーは {{ic|\EFI\arch\grub.efi}} です。

==== レスキューシェルが起動する ====

GRUB はロードされたが、エラーが表示されずにレスキューシェルに落とされる場合、以下の2つの理由のうち1つが原因である可能性があります:

* {{ic|grub.cfg}} が存在しないか、場所を間違えている。{{ic|--boot-directory}} を使って GRUB UEFI をインストールして、{{ic|grub.cfg}} が存在しない場合に起こります。
* ブートパーティションが変更された ({{ic|grubx64.efi}} ファイルにハードコードされています)。

==== GRUB UEFI がロードされない ====

有効な UEFI の例:

{{hc|# efibootmgr -u|
BootCurrent: 0000
Timeout: 3 seconds
BootOrder: 0000,0001,0002
Boot0000* GRUB HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EFI\GRUB\grubx64.efi)
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\shellx64.efi)
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI
}}

画面が数秒間真っ暗になって、その後、次のブートオプションが試行される場合、[https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 この投稿]によると、GRUB をルートパーティションに移動することで直るかもしれません。ブートオプションは削除して後でまた作成する必要があります。GRUB のエントリは次のようにしてください:

Boot0000* GRUB HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grubx64.efi)

==== デフォルト/フォールバックのブートパス ====

一部の UEFI ファーウェアではブート可能なファイルが既知の場所に存在している必要があり、それ以外の場所では UEFI NVRAM ブートエントリに表示されません。この場合、{{ic|grub-install}} が、GRUB を起動するエントリが {{ic|efibootmgr}} によって追加されたと報告するでしょうが、VisualBIOS のブート順序セレクターには表示されません。解決策は GRUB をデフォルト/フォールバックのブートパスにインストールすることです:

# grub-install --target=x86_64-efi --efi-directory=''esp'' '''--removable'''

あるいは、すでにインストールされた GRUB の EFI 実行ファイルをデフォルト/フォールバックのパスに移動することができます:

# mv ''esp''/EFI/grub ''esp''/EFI/BOOT
# mv ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/BOOTX64.EFI

=== Invalid signature ===

(例えば、パーティションを再設定したり、追加のハードドライブを追加したりしたあとで) Windows を起動しようとして "invalid signature" エラーが発生する場合、GRUB のデバイス設定を移動 (削除) し、GRUB に再設定させてください:

# mv /boot/grub/device.map /boot/grub/device.map-old
# grub-mkconfig -o /boot/grub/grub.cfg

これで {{ic|grub-mkconfig}} は Windows を含む全てのブートオプションを記述したはずです。これで動作したら、{{ic|/boot/grub/device.map-old}} は削除してください。

=== 起動中にフリーズする ===

GRUB がカーネルと初期 RAM ディスクをロードした後に、エラーメッセージが表示されずにフリーズする場合、{{ic|add_efi_memmap}} カーネルパラメータを削除してみてください。

=== 他の OS から Arch が見つからない ===

他のディストリビューションで {{ic|os-prober}} を使って Arch Linux を自動的に検索できないという報告が複数確認されています。この問題が発生する場合、{{ic|/etc/lsb-release}} をおくことで検知が改善されると報告されています。このファイルと更新ツールは[[公式リポジトリ]]にある {{Pkg|lsb-release}} パッケージから利用可能です。

=== chroot でインストールした時に警告が表示される ===

(システムのインストール中などに) chroot 環境で LVM システム上に GRUB をインストールする際に、以下のような警告が発生する場合があります:

/run/lvm/lvmetad.socket: connect failed: No such file or directory

または

WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.

これは、{{ic|/run}} が chroot 内で利用可能でないから起こります。すべてが正しく行われていれば、これらの警告のせいでシステムが起動できなくなることはありません。インストールを継続することができます。

=== GRUB のロードが遅い ===

ディスク容量が残りわずかの場合 GRUB がロードされるのにかなり時間がかかることがあります。起動が遅い場合 {{ic|/boot}} や {{ic|/}} に十分な空き容量があるか確認してください。

=== error: unknown filesystem ===

GRUB が {{ic|error: unknown filesystem}} と出力して起動しない理由はいくつか考えられます。[[UUID]] が正しいこと、全てのファイルシステムが問題なく、GRUB によってサポートされていることが確認できる場合、[[#GUID Partition Table (GPT) 特有の手順|BIOS Boot Partition]] がドライブの最初の 2TB の中にない可能性があります [https://bbs.archlinux.org/viewtopic.php?id=195948]。適当なパーティショニングツールを使ってパーティションが最初の 2TB 以内にあるようにして、GRUB を再インストール・再設定してください。

また、このエラーは [[ext4]] ファイルシステムがいくつかの機能をサポートしていないことが原因かもしれません:
* {{ic|large_dir}} - サポートされません。
* {{ic|metadata_csum_seed}} - GRUB 2.11 でサポートされます ([https://git.savannah.gnu.org/cgit/grub.git/commit/?id=7fd5feff97c4b1f446f8fcf6d37aca0c64e7c763 コミット]).

{{Warning| {{ic|/boot}} ファイルシステム上で[[ファイルシステム]]の新しい機能を有効化する前に、GRUB がそれらをサポートしていることを確認してください。}}

=== grub-reboot で再設定されない ===

GRUB は Btrfs のルートパーティションに書き込むを行うことができません [https://bbs.archlinux.org/viewtopic.php?id=166131]。grub-reboot を使って他のエントリを起動した場合、ディスク上の環境を更新することができなくなります。(ディストリビューションを切り替えるなどの場合に) 他のエントリから grub-reboot を実行するか他のファイルシステムを使ってください。{{ic|grub-editenv create}} を実行して {{ic|/etc/default/grub}} に {{ic|GRUB_DEFAULT<nowiki>=</nowiki>0}} を設定することでエントリをリセットできます (設定後は {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} を行ってください)。

=== 古い Btrfs のせいでインストールができない ===

パーティションテーブルを作成しないで Btrfs を使ってドライブをフォーマットしている場合 (例: {{ic|/dev/sdx}})、後からパーティションテーブルを書き込むと、Btrfs のフォーマットが一部残留します。ほとんどのユーティリティや OS は残留した Btrfs を認識できないため、GRUB は (たとえ --force が付けられていても) インストールを拒否します:

# grub-install: warning: Attempting to install GRUB to a disk with multiple partition labels. This is not supported yet..
# grub-install: error: filesystem `btrfs' does not support blocklists.

ドライブを完全に消去してもいいですが、{{ic|wipefs -o 0x10040 /dev/sdx}} を使えばデータを残して Btrfs のスーパーブロックだけを消去することができます。

=== Windows 8/10 が認識されない ===

Windows 8/10 の "高速スタートアップ"、"ハイブリッドブート"、"Hiberboot" と呼ばれる設定を有効にしていると Windows のパーティションをマウントすることができなくなる可能性があります。そのため {{ic|grub-mkconfig}} が Windows を認識することができなくなります。Windows で高速スタートアップを無効化することで GRUB のメニューに追加することができるようになるはずです。

=== grub-rescue プロンプトと暗号化済み /boot ===

[[#暗号化された /boot|暗号化済みの /boot]] を使用している場合に間違ったパスワードを入力してしまうと grub-rescue プロンプトに入ります。

この grub-rescue プロンプトではできることが限られています。以下のコマンドを使ってブートを完了させます:

{{bc|
grub rescue> cryptomount <partition>
grub rescue> insmod normal
grub rescue> normal
}}

より良い説明は[https://blog.stigok.com/2017/12/29/decrypt-and-mount-luks-disk-from-grub-rescue-mode.html このブログ投稿]{{Dead link|2023|04|23|status=404}}をご覧ください。

=== GRUB をインストールしたが起動時にメニューが表示されない ===

{{ic|/etc/default/grub}} を見て {{ic|GRUB_TIMEOUT}} が {{ic|0}} に設定されていないかチェックしてください。{{ic|0}} に設定されていた場合、正の数に設定し直してください。この値はデフォルトの GRUB エントリが起動されるまでの秒数を表しています。{{ic|GRUB_TIMEOUT_STYLE}} が {{ic|hidden}} に設定されていないかもチェックしてください。{{ic|hidden}} に設定されていた場合、{{ic|menu}} に設定し直してください。これでメニューがデフォルトで表示されるようになります。以上が終わったら、[[#メイン設定ファイルの生成|メインの設定ファイルを再生成]]して、再起動してメニューが表示されるか確かめてください。

これでうまく行かない場合、グラフィカルターミナルとの互換性の問題があるのかもしれません。{{ic|/etc/default/grub}} で {{ic|GRUB_TERMINAL_OUTPUT}} を {{ic|console}} に設定し、GRUB のグラフィカルターミナルを無効化してください。

== 参照 ==

* [[Wikipedia:ja:GNU GRUB]]
* [https://www.gnu.org/software/grub/manual/grub.html 公式 GRUB マニュアル]
* [https://help.ubuntu.com/community/Grub2 Ubuntu wiki の GRUB ページ]
* [https://help.ubuntu.com/community/UEFIBooting UEFI システム用にコンパイルする手順を説明している GRUB wiki ページ]
* [[Wikipedia:BIOS Boot partition]]
* [https://web.archive.org/web/20160424042444/http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html#Editing_etcgrub.d05_debian_theme How to configure GRUB]

{{TranslationStatus|GRUB|2024-08-26|812848}}

Unified Extensible Firmware Interface/セキュアブート

2026-05-07T06:03:41Z

ELC: /* 公式の ISO をカスタムの鍵で署名する */ shellia32.efi が配布されなくなったので該当部分を削除

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[hu:Unified Extensible Firmware Interface (Magyar)/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ([https://gitlab.archlinux.org/archlinux/archiso/-/issues/69 archlinux/archiso#69])。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://archboot.com/ Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ The Meaning of all the UEFI Keys] を見てください。

セキュアブートをを使用するには最低でも '''PK''', '''KEK''', '''db''' 鍵が必要です。KEK, db, dbx 証明書は複数追加できますが、Platform Key はひとつしか使えません。

Secure Boot を "User Mode" にすると、上位の鍵を使用してアップデートに署名しないかぎり鍵を更新できなくなります (''sign-efi-sig-list'' を使用)。Platform key は自分自身で署名することができます。

==== OpROM 署名を特定する ====

署名された OpROM があるかどうかを確認するには、次の手順に従います。

OpROM を搭載したすべてのデバイスを一覧表示します:

{{hc|$ find /sys/devices/ -name rom|
/sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
...
}}

これは、署名付き EFI ROM を搭載した Intel DC SSD の例です。デバイスごとに以下の手順を繰り返してください。

{{hc|$ lspci -s 81:00.0|
81:00.0 Non-Volatile memory controller: Intel Corporation PCIe Data Center SSD (rev 01)
}}

ROM をダンプします:

# echo 1 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
# cat /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom > ~/intel_ssd.rom
# echo 0 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom

TianoCore の [https://github.com/tianocore/edk2.git EDK II ツール] 取得してコンパイルします:

$ make -C BaseTools

ROM ファイルを解析します:

{{hc|$ ./BaseTools/Source/C/bin/EfiRom -d ~/intel_ssd.rom|
Image 1 -- Offset 0x0
ROM header contents
Signature 0xAA55
PCIR offset 0x001C
Signature PCIR
Vendor ID 0x8086
Device ID 0x0953
Length 0x001C
Revision 0x0003
DeviceListOffset 0x00
Class Code 0x000000
Image size 0x6A00
Code revision: 0x0000
MaxRuntimeImageLength 0x00
ConfigUtilityCodeHeaderOffset 0x00
DMTFCLPEntryPointOffset 0x00
Indicator 0x80 (last image)
Code type 0x03 (EFI image)
EFI ROM header contents
EFI Signature 0x0EF1
Compression Type 0x0001 (compressed)
Machine type 0x8664 (X64)
Subsystem 0x000B (EFI boot service driver)
EFI image offset 0x0038 (@0x38)
}}

これはこの OpROM に、オフセット 0x0 のイメージ 1 の、オフセット 0x0038 に圧縮された EFI イメージがあることを示します。

EFI セクションを取得します:

$ dd if=intel_ssd.rom ibs=1 skip=$(( 0x00 + 0x38 )) of=intel_ssd.rom.efi.compressed

バイナリイメージを解凍します:

$ ./BaseTools/Source/C/bin/TianoCompress -d --uefi -v ~/intel_ssd.rom.efi.compressed -o ~/intel_ssd.rom.efi

{{hc|$ file ../intel_ssd.rom.efi|
../intel_ssd.rom.efi: PE32+ executable for EFI (boot service driver), x86-64, 6 sections
}}

{{Pkg|sbsigntools}} で署名を調べると、Microsoft の DB 証明書で署名されていることがわかります:

{{hc|$ sbverify --list ~/intel_ssd.rom.efi|2=
signature 1
image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root
}}

{{Warning|デバイスの文鎮化を回避するために、署名された ROM を搭載したグラフィックカードを使用している場合は、独自のキーを登録した後、セキュアブート DB に必要な発行者が保持されていることを確認してください。}}

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== GRUB で sbctl を使う =====

[[GRUB#セキュアブートサポート]] を見てください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。あるいは、以下のようにすることもできます:

# sbctl verify {{!}} sed -E 's{{!}}^.* (/.+) is not signed${{!}}sbctl sign -s "\1"{{!}}e'

これはファイルパスに依存せず、「✗」文字は必要ありません。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -keyout PK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Platform Key''/" -out PK.crt
$ openssl x509 -outform DER -in PK.crt -out PK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth

"User Mode" で Platform Key を削除できるようにするために空のファイルを署名してください:

$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -keyout KEK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Key Exchange Key''/" -out KEK.crt
$ openssl x509 -outform DER -in KEK.crt -out KEK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth

Signature Database key:

$ openssl req -newkey rsa:4096 -noenc -keyout db.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Signature Database key''/" -out db.crt
$ openssl x509 -outform DER -in db.crt -out db.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/etc/efi-keys/}})、スクリプトを実行してください:

# mkdir /etc/efi-keys
# cd !$
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh
# chmod +x mkkeys.sh
# ./mkkeys.sh
''鍵に埋め込む Common Name を入力 (例: "Secure Boot")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''sbsign'' を使用してください。例えば:

# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key db.key --cert db.crt --output ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/BOOTx64.EFI

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

key=''/path/to/''db.key
cert=''/path/to/''db.crt

if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign "$kernel" --key "$key" --cert "$cert" --output "$kernel"
fi}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ cert-to-efi-sig-list -g "$(< GUID.txt)" ''new_db''.crt ''new_db''.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

db 鍵を置き換えるかわりに Signature Database に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|db}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|loader.efi}} を UEFI によって自動的に起動されるデフォルトのブートローダーの場所にコピーしてください:

# cp /usr/share/preloader-signed/HashTool.efi ''esp''/EFI/BOOT/
# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/BOOT/loader.efi

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI

''shim'' は、MokList に格納されている Machine Owner Key やハッシュによってバイナリを認証することができます。

; Machine Owner Key (MOK): EFI バイナリに署名するためにユーザが生成し利用する鍵
; hash: EFI バイナリの SHA256 ハッシュ

ハッシュを用いるのは単純ですが、ブートローダやカーネルをアップデートするたびに、MokManager 内のそれらのハッシュを追加する必要があります。MOK では鍵を一度追加するだけで済みますが、ブートローダとカーネルをアップデートするたびに、それらに署名する必要があります。

====== shim でハッシュを使う ======

''shim'' は、MokList に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -nodes -keyout MOK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Machine Owner Key''/" -out MOK.crt
$ openssl x509 -outform DER -in MOK.crt -out MOK.cer

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|grubx64.efi}} という名前の) ブートローダーとカーネルに署名:

# sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

key=''/path/to/''MOK.key
cert=''/path/to/''MOK.crt

if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign "$kernel" --key "$key" --cert "$cert" --output "$kernel"
fi}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

{{Expansion|shim を含めるように ISO を再パックするための手順を追加してください。}}

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。以下の手順に従うか、自動化された代替手段として {{AUR|gsai-git}} を使用してください。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-cpx /arch/boot/x86_64/vmlinuz-linux \
/EFI/BOOT/BOOTx64.EFI \
/EFI/BOOT/BOOTIA32.EFI \
/shellx64.efi ./
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ sbsign --key db.key --cert db.crt --output BOOTx64.EFI BOOTx64.EFI
$ sbsign --key db.key --cert db.crt --output BOOTIA32.EFI BOOTIA32.EFI
$ sbsign --key db.key --cert db.crt --output shellx64.efi shellx64.efi
$ sbsign --key db.key --cert db.crt --output vmlinuz-linux vmlinuz-linux

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI BOOTIA32.EFI ::/EFI/BOOT/
$ mcopy -D oO -i eltorito_img2_uefi.img shellx64.efi ::/

変更された El Torito UEFI ブートイメージを使って ISO を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2026-03-12|862815}}

ユニファイドカーネルイメージ

2026-03-12T03:01:00Z

ELC: /* mkinitcpio */ スクリプトを簡略化

[[Category:ブートローダー]]
[[en:Unified kernel image]]
[[pt:Unified kernel image]]
[https://uapi-group.org/specifications/specs/unified_kernel_image ユニファイドカーネルイメージ] (UKI) は、単一の実行可能ファイルであり、[[UEFI]] ファームウェアから直接起動するか、ほとんどまたは全く設定を必要とせずにブートローダーによって自動的に取得されます。これは {{man|7|systemd-stub}} のような UEFI ブートスタブプログラム、Linux [[Arch ブートプロセス#カーネル|カーネルイメージ]]、[[Arch ブートプロセス#initramfs|initrd]]、および [https://uapi-group.org/specifications/specs/unified_kernel_image/#uki-components その他のリソース] を単一の UEFI PE ファイルに組み合わせたものです。

このファイルは、したがってこれらのすべての要素を[[Unified Extensible Firmware Interface/セキュアブート# EFI バイナリに署名する|署名]]して [[Secure Boot]] で使用することが容易になります。

{{Note|記事全体で {{ic|''esp''}} は [[EFI システムパーティション]] のマウントポイントを表します。}}

== ユニファイドカーネルイメージの準備 ==

UKI (Unified Kernel Image) イメージを生成し、適切な場所 ("esp/Linux" ディレクトリ) にインストールする方法はいくつかあります。現在、この機能を実行するためのツールがいくつか競合しているので、ニーズと好みに応じて以下のいずれかを選択してください。

{{Note|
* 以下のいずれかのサブセクションを実行するだけで済みます。
* UKI を [[Unified Extensible Firmware Interface#Default boot path for removable drives|フォールバックブートパス]] {{ic|''esp''/EFI/BOOT/BOOTx64.EFI}} (または 32 ビット IA32 UEFI の場合は {{ic|BOOTIA32.EFI}}) に配置することも可能です。フォールバックブートパスを使用すると、NVRAM に UEFI ブートエントリを明示的に作成する必要がなくなります。
}}

=== mkinitcpio ===

[[mkinitcpio]] は、{{Pkg|systemd-ukify}} がインストールされていない限り、UKI (Unified Kernel Image) を自身で組み立てます。{{Pkg|systemd-ukify}} がインストールされている場合は、{{ic|--no-ukify}} オプションで明示的に無効にしない限り、UKI の作成は "ukify" にオフロードされます。

==== カーネルコマンドライン ====

[[mkinitcpio]] は、{{ic|/etc/cmdline.d}} ディレクトリ内のコマンドラインファイルからの[[カーネルパラメータ]]の読み取りをサポートします。Mkinitcpio は、このディレクトリ内の {{ic|.conf}} 拡張子を持つすべてのファイルの内容を連結し、それらを使用してカーネルコマンドラインを生成します。コマンドラインファイル内の ''#'' 文字で始まる行はコメントとして扱われ、mkinitcpio によって無視されます。マイクロコードと initramfs を指す ''エントリを削除'' するように注意してください。

例:

{{hc|/etc/cmdline.d/root.conf|2=
root=UUID=0a3407de-014b-458b-b5c1-848e92a327a3 rw
}}

{{Tip|
* ルートファイルシステムがデフォルト以外の Btrfs サブボリューム上にある場合は、必ず必要なマウントフラグを {{ic|rootflags}} に設定してください。[[Btrfs#サブボリュームをルートとしてマウントする]] を参照してください。
* たとえば、システムのサブボリューム ID が {{ic|256}} の場合 (サブボリューム ID は、{{ic|btrfs subvolume list ''btrfs_mountpoint''}} を使用して確認できます。または、{{ic|/etc/fstab}}) でフラグを見ることができます、カーネルコマンドラインに {{ic|1=rootflags=subvolid=256}} を追加する必要があります。
* {{ic|rootflags}} は起動時にのみ使用されるため、{{ic|/etc/fstab}} 内のすべてのフラグをコピーする必要はありません。Systemd は fstab を読み取り、再マウントし、ブート後にそこにリストされているフラグを自動的に適用します。
}}

{{hc|/etc/cmdline.d/security.conf|2=
# enable apparmor
lsm=landlock,lockdown,yama,integrity,apparmor,bpf audit=1 audit_backlog_limit=256
}}

あるいは、{{ic|/etc/kernel/cmdline}} を使用してカーネルコマンドラインを設定することもできます。

例:

{{hc|/etc/kernel/cmdline|2=
root=UUID=0a3407de-014b-458b-b5c1-848e92a327a3 rw quiet bgrt_disable
}}

{{Tip|
* root パーティションが [[systemd#GPT パーティションの自動マウント|systemd によって自動マウントされる]] 場合、{{ic|1=root=}} パラメータは省略できます。
* {{ic|bgrt_disable}} パラメータは、ACPI テーブルのロード後に OEM ロゴを表示しないように Linux に指示します。
}}

==== .preset ファイル ====

次に、{{ic|/etc/mkinitcpio.d/linux.preset}}、または使用しているプリセットを、[[EFI システムパーティション]] の適切なマウントポイントを指定して、以下のように変更します:

* {{ic|1=PRESETS=}} の各項目について、{{ic|1=''PRESET''_uki=}} パラメータのコメントを解除する (つまり {{ic|#}} を削除する)、
* 冗長な {{ic|initramfs-*.img}} ファイルを保存しないように、{{ic|1=''PRESET''_image=}} をコメントアウトする、
* オプションとして、スプラッシュイメージを追加したい各 {{ic|1=''PRESET''_options=}} 行に {{ic|--splash}} パラメータを追加またはコメント解除します。

以下は {{Pkg|linux}} カーネルと Arch スプラッシュスクリーンの {{ic|linux.preset}} の例です。

{{hc|/etc/mkinitcpio.d/linux.preset|2=
# mkinitcpio preset file for the 'linux' package

#ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/vmlinuz-linux"

PRESETS=('default' 'fallback')

#default_config="/etc/mkinitcpio.conf"
#default_image="/boot/initramfs-linux.img"
default_uki="''esp''/EFI/Linux/arch-linux.efi"
default_options="--splash=/usr/share/systemd/bootctl/splash-arch.bmp"

#fallback_config="/etc/mkinitcpio.conf"
#fallback_image="/boot/initramfs-linux-fallback.img"
fallback_uki="''esp''/EFI/Linux/arch-linux-fallback.efi"
fallback_options="-S autodetect"
}}

{{Tip|
* 統一されたカーネルイメージからブートしたいだけであれば、[[EFI システムパーティション#典型的なマウントポイント|ESP のマウント]]を {{ic|/efi}} にして、[[ESP]] パーティションに存在する必要があるものだけをマウントすることができます。
* {{ic|--cmdline /etc/kernel/''fallback_cmdline''}} を {{ic|fallback_options}} に追加することで、フォールバックイメージに上記とは異なる [[Unified カーネルイメージ#カーネルコマンドライン|cmdline]] を使用することができます (例えば {{ic|quiet}} を無くす。)
* カーネルコマンドラインの埋め込みを省略するには、{{ic|--no-cmdline}} を {{ic|1=''PRESET''_options=}} に追加してください。カーネルパラメーターはブートローダー経由で渡す必要があります。
}}

{{Note|
* {{ic|''PRESET''_uki}} オプションは以前は {{ic|''PRESET''_efi_image}} として知られていました。[https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/issues/134 2022 年 11 月変更], 古いオプションは非推奨ですが、今のところ動作しています。
* [[Unified Extensible Firmware Interface# UEFI ファームウェアのビット数|IA32 UEFI]] では、{{ic|--uefistub /usr/lib/systemd/boot/efi/linuxia32.efi.stub}} を {{ic|1=''PRESET''_options=}} に追加してください。
}}

==== pacman フック ====

systemd-stub ({{pkg|systemd}} の一部)、microcode ({{pkg|intel-ucode}} と {{pkg|amd-ucode}} の両方)、および {{pkg|linux}} カーネルの更新は、自動的に UKI (Unified Kernel Image) の再構築をトリガーします。ただし、{{ic|/etc/pacman.d/hooks/}} ディレクトリにある他の [[pacman フック]] (例えば、[[NVIDIA#pacman hook|NVIDIA ドライバー]] のものなど) を確認することをお勧めします。

==== UKI の構築 ====

最後に、UKI のディレクトリが存在することを確認し、[[mkinitcpio#イメージ作成とアクティベーション|initramfs を再生成]] します。たとえば、''linux'' プリセットの場合は次のようになります。

# mkdir -p ''esp''/EFI/Linux
# mkinitcpio -p linux

必要に応じて、残っている {{ic|initramfs-*.img}} を {{ic|/boot}} または {{ic|/efi}} から削除します。

=== kernel-install ===

確実に kernel-install が [[Kernel-install#自動で|正しく設定されている]] ことを確認してください。

UKI を生成するには、{{Pkg|systemd-ukify}} をインストールし、{{ic|kernel-install}} の layout を {{ic|uki}} に設定します。

{{hc|/etc/kernel/install.conf|
2=layout=uki}}

{{Note|[[mkinitcpio]] が initrd を作成し、その後 [[#ukify]] が UKI を生成します。}}

[[#ukify]] の設定は、[[kernel-install]] で使用するために、{{ic|/etc/kernel/uki.conf}} で行う必要があります。例:

{{hc|/etc/kernel/uki.conf|
2=[UKI]
Splash=/usr/share/systemd/bootctl/splash-arch.bmp
}}

{{Tip|{{ic|/usr/lib/kernel/uki.conf}} から {{ic|/etc/kernel/uki.conf}} にテンプレートをコピーし、セクションタイトルと役立つ行をコメントアウトすることもできます。このファイルにカーネルコマンドラインを設定しないでください。無視されます。[[Kernel-install#カーネルコマンドライン]] を使用してください。}}

あるいは、mkinitcpio が UKI を生成するように、それをデフォルトの {{ic|uki_generator}} として設定します。

{{hc|/etc/kernel/install.conf|
2=layout=uki
uki_generator=mkinitcpio}}

この場合、{{Pkg|systemd-ukify}} は不要です。別の {{ic|initrd_generator}} を設定することもできます。{{Man|8|kernel-install}} を参照してください。

変更を有効にするには、使用しているカーネルパッケージを再インストールしてください。

=== dracut ===

こちらを参照して下さい [[dracut#ユニファイドカーネルイメージ]] と [[dracut#カーネルのアップグレード時に新しい initramfs を生成]]

=== ukify ===

{{Pkg|systemd-ukify}} パッケージを [[インストール]] します。''ukify'' は単独で initramfs を生成できないため、必要な場合は、[[dracut]]、[[mkinitcpio]]、または [[booster]] を使用して生成する必要があります。

最小限の動作例は次のようになります。

# ukify build --linux=''/boot/vmlinuz-linux'' \
--initrd=''/boot/initramfs-linux.img'' \
--cmdline="''quiet rw''"

{{Note|[[マイクロコード#早期ロード|外部マイクロコード initramfs イメージ]] を使用する場合 ({{ic|/boot/amd-ucode.img}} または {{ic|/boot/intel-ucode.img}}) を使用する必要があります。常にメインの initramfs イメージの前に ''最初に'' 配置します (例: {{ic|/boot/initramfs-linux.img}})}}

{{Tip|
* 出来上がった EFI 実行ファイルを EFI システムパーティションにコピーするのをスキップするには、{{ic|1=--output=''esp''/EFI/Linux/''filename''.efi}} コマンドラインオプションを ''ukify'' に使用します。
* {{ic|--cmdline}} オプションを指定する場合、{{ic|1=--cmdline=@''/path/to/cmdline''}} のように {{ic|/etc/kernel/cmdline}} ファイル名の前に {{ic|@}} シンボルを追加することで、カーネルパラメータを読み込むファイル名を指定できます。
}}

詳細については、{{man|1|ukify}}を参照してください。

intel ucode および /efi マウント ESP を使用した通常のカーネルイメージの systemd サービスを使用した自動 UKI 構築の例:

{{Note|カーネル、マイクロコード、または initramfs が変更されたときに UKI が自動的に更新されるようにするには、例えば [[kernel-install]] や [[mkinitcpio]] と共に ukify を使用するだけです。詳細については、上記のセクション [[#kernel-install]] および [[#mkinitcpio]] を参照してください。}}

=== 手動で ===

使用するカーネルコマンドラインをファイルに記述し、{{man|1|objcopy}} を使用してバンドルファイルを作成します。

[[マイクロコード]] の場合は、まず次のようにマイクロコードファイルと initrd を連結します。

$ cat ''esp''/''cpu_manufacturer''-ucode.img ''esp''/initramfs-linux.img > /tmp/combined_initrd.img

統合カーネルイメージを構築するときは、{{ic|/tmp/combined_initrd.img}} を initrd として渡します。このファイルは後で削除できます。

{{Note|[[Unified Extensible Firmware Interface#UEFI ファームウェアのビット数|IA32 UEFI]] では、以下のコマンドの {{ic|/usr/lib/systemd/boot/efi/linuxx64.efi.stub}} を {{ic|/usr/lib/systemd/boot/efi/linuxia32.efi.stub}} に置き換えてください。}}

{{bc|1=
$ align="$(objdump -p /usr/lib/systemd/boot/efi/linuxx64.efi.stub {{!}} awk '{ if ($1 == "SectionAlignment"){print $2} }')"
$ align=$((16#$align))
$ osrel_offs="$(objdump -h "/usr/lib/systemd/boot/efi/linuxx64.efi.stub" {{!}} awk 'NF==7 {size=strtonum("0x"$3); offset=strtonum("0x"$4)} END {print size + offset}')"
$ osrel_offs=$((osrel_offs + "$align" - osrel_offs % "$align"))
$ cmdline_offs=$((osrel_offs + $(stat -Lc%s "/usr/lib/os-release")))
$ cmdline_offs=$((cmdline_offs + "$align" - cmdline_offs % "$align"))
$ splash_offs=$((cmdline_offs + $(stat -Lc%s "/etc/kernel/cmdline")))
$ splash_offs=$((splash_offs + "$align" - splash_offs % "$align"))
$ initrd_offs=$((splash_offs + $(stat -Lc%s "/usr/share/systemd/bootctl/splash-arch.bmp")))
$ initrd_offs=$((initrd_offs + "$align" - initrd_offs % "$align"))
$ linux_offs=$((initrd_offs + $(stat -Lc%s "''initrd-file''")))
$ linux_offs=$((linux_offs + "$align" - linux_offs % "$align"))

$ objcopy \
--add-section .osrel="/usr/lib/os-release" --change-section-vma .osrel=$(printf 0x%x $osrel_offs) \
--add-section .cmdline="/etc/kernel/cmdline" \
--change-section-vma .cmdline=$(printf 0x%x $cmdline_offs) \
--add-section .splash="/usr/share/systemd/bootctl/splash-arch.bmp" \
--change-section-vma .splash=$(printf 0x%x $splash_offs) \
--add-section .initrd="''initrd-file''" \
--change-section-vma .initrd=$(printf 0x%x $initrd_offs) \
--add-section .linux="''vmlinuz-file''" \
--change-section-vma .linux=$(printf 0x%x $linux_offs) \
"/usr/lib/systemd/boot/efi/linuxx64.efi.stub" "''linux''.efi"
}}

注意すべき点がいくつかあります:

* [https://github.com/systemd/systemd/commit/0fa2cac4f0cdefaf1addd7f1fe0fd8113db9360b#commitcomment-76747223] で推奨されているように、オフセットは動的に計算されるので、セクションが重なることはありません。
* セクションは、PE スタブの {{ic|SectionAlignment}} フィールドが示す値 (通常は 0x1000) にアラインメントされます。
* カーネルイメージは、[https://github.com/systemd/systemd/commit/0fa2cac4f0cdefaf1addd7f1fe0fd8113db9360b#commitcomment-84868898] で述べられているように、インプレース解凍で後続のセクションが上書きされるのを防ぐために、最後のセクションにある必要があります。

イメージを作成したら、それを EFI システムパーティションにコピーします。

# cp ''linux''.efi ''esp''/EFI/Linux/

== セキュアブート用の UKI への署名 ==

=== sbctl ===

{{Pkg|sbctl}} は、更新されたバイナリに署名するための [[kernel-install]] スクリプト、[[mkinitcpio]] ポストフック、および pacman フックを提供します。

=== mkinitcpio ===

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使用することで、生成された Unified Kernel Image に [[セキュアブート]] 用の署名を付けることができます。以下のファイルを作成し、[[ヘルプ:読み方#実行可能属性の付与|実行可能]]にしてください。

{{hc|/etc/initcpio/post/uki-sbsign|2=
#!/usr/bin/env bash

uki="$3"
<nowiki>[[ -n "$uki" ]] || exit 0</nowiki>

key=''/path/to/''db.key
cert=''/path/to/''db.crt

if ! sbverify --cert "$cert" "$uki" &>/dev/null; then
sbsign "$uki" --key "$key" --cert "$cert" --output "$uki"
fi}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} を、イメージの署名に使用するキーペアのパスに置き換えてください。

=== ukify ===

{{Pkg|sbsigntools}} をインストールし、{{ic|/etc/kernel/uki.conf}} で {{ic|--secureboot-private-key}} と {{ic|--secureboot-certificate}} を指定します。

== 起動方法 ==

{{Note|[[セキュアブート]] がアクティブな場合、{{ic|.cmdline}} が埋め込まれた統合カーネルイメージは、(ブートエントリを使用するか対話的に) 渡されたすべてのコマンドラインオプションを無視します。セキュアブートがアクティブでない場合、コマンドライン経由で渡されたオプションは、埋め込まれた {{ic|.cmdline}} をオーバーライドします。}}

=== Limine ===

[[Limine]] は Unified Kernel Image (UKI) を自動的に検出しません。ただし、{{ic|limine.conf}} を手動で構成して UKI をロードできます。

'''例 1: デフォルトの EFI システムパーティションから UKI を起動する'''

UKI ファイルが {{ic|''esp''/EFI/Linux/}} に保存されている場合は、次の設定を {{ic|limine.conf}} に追加します。

{{hc|limine.conf|2=
/Arch Linux
protocol: efi_chainload
image_path: boot():/EFI/Linux/arch-linux.efi
}}

'''例 2: 別の EFI パーティションから UKI を起動する'''

UKI ファイルが別のディスク上の別の EFI パーティションにある場合は、{{ic|uuid(''partition UUID'')}} を使用します。

{{Note|パーティション UUID はファイルシステム UUID '''ではありません'''。{{ic|PARTUUID}} としてパーティション UUID を見つけるには、次を使用します。
$ lsblk -o NAME,FSTYPE,PARTUUID,PARTTYPENAME,MOUNTPOINT,SIZE,LABEL
}}

{{hc|limine.conf|2=
/Arch Linux
protocol: efi_chainload
image_path: uuid(''xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx''):/EFI/Linux/arch-linux.efi
}}

サポートされているパスと設定オプションの詳細については、[https://github.com/limine-bootloader/limine/blob/v8.x/CONFIG.md#Paths Limine Paths ドキュメント] を参照してください。

=== systemd-boot ===

[[systemd-boot#Unified kernel images|systemd-boot]] は {{ic|''esp''/EFI/Linux/}} 内でユニファイドカーネルイメージを検索しますので、それ以上の設定は必要ありません。{{man|7|sd-boot|FILES}} を見て下さい。

=== rEFInd ===

[[rEFInd]] は、EFI システムパーティション上のユニファイドカーネルイメージを自動検出し、それらをロードできます。{{ic|refind.conf}} で手動で指定することもできます。デフォルトでは次の場所にあります。

{{hc|''esp''/EFI/refind/refind.conf|2=
menuentry Linux {
loader ''esp''/EFI/Linux/archlinux-linux.efi
}
}}

イメージが ESP のルートにある場合、rEFInd は次のようにその名前のみを必要とします: {{ic|loader archlinux-linux.efi}} この方法で起動すると、{{ic|''esp''/EFI/refind_linux.conf}} からのカーネルパラメータは渡されません。

=== GRUB ===

rEFInd と同様に、[[GRUB]] は [[GRUB#ユニファイドカーネルイメージをチェインロード]] で説明されているように EFI UKI をチェーンロードできます。

=== UEFI から直接起動 ===

[[efibootmgr]] を使って ''.efi'' ファイルに UEFI ブートエントリを作成することができます。

# efibootmgr --create --disk /dev/sd''X'' --part ''partition_number'' --label "Arch Linux" --loader '\EFI\Linux\arch-linux.efi' --unicode

オプションの説明は {{man|8|efibootmgr}} をご覧ください。

== 参照 ==

* [https://www.youtube.com/watch?v=7UhwK3g99_0 All Systems Go! talk on UKIs]
* [https://uapi-group.org/specifications/specs/unified_kernel_image/ Unified kernel image specification]
* [https://linderud.dev/blog/mkinitcpio-v31-and-uefi-stubs/ mkinitcpio v31 and UEFI stubs]

Unified Extensible Firmware Interface/セキュアブート

2026-03-12T02:53:22Z

ELC: /* インストールメディアを起動する */ リンク修正

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[hu:Unified Extensible Firmware Interface (Magyar)/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ([https://gitlab.archlinux.org/archlinux/archiso/-/issues/69 archlinux/archiso#69])。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://archboot.com/ Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ The Meaning of all the UEFI Keys] を見てください。

セキュアブートをを使用するには最低でも '''PK''', '''KEK''', '''db''' 鍵が必要です。KEK, db, dbx 証明書は複数追加できますが、Platform Key はひとつしか使えません。

Secure Boot を "User Mode" にすると、上位の鍵を使用してアップデートに署名しないかぎり鍵を更新できなくなります (''sign-efi-sig-list'' を使用)。Platform key は自分自身で署名することができます。

==== OpROM 署名を特定する ====

署名された OpROM があるかどうかを確認するには、次の手順に従います。

OpROM を搭載したすべてのデバイスを一覧表示します:

{{hc|$ find /sys/devices/ -name rom|
/sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
...
}}

これは、署名付き EFI ROM を搭載した Intel DC SSD の例です。デバイスごとに以下の手順を繰り返してください。

{{hc|$ lspci -s 81:00.0|
81:00.0 Non-Volatile memory controller: Intel Corporation PCIe Data Center SSD (rev 01)
}}

ROM をダンプします:

# echo 1 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
# cat /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom > ~/intel_ssd.rom
# echo 0 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom

TianoCore の [https://github.com/tianocore/edk2.git EDK II ツール] 取得してコンパイルします:

$ make -C BaseTools

ROM ファイルを解析します:

{{hc|$ ./BaseTools/Source/C/bin/EfiRom -d ~/intel_ssd.rom|
Image 1 -- Offset 0x0
ROM header contents
Signature 0xAA55
PCIR offset 0x001C
Signature PCIR
Vendor ID 0x8086
Device ID 0x0953
Length 0x001C
Revision 0x0003
DeviceListOffset 0x00
Class Code 0x000000
Image size 0x6A00
Code revision: 0x0000
MaxRuntimeImageLength 0x00
ConfigUtilityCodeHeaderOffset 0x00
DMTFCLPEntryPointOffset 0x00
Indicator 0x80 (last image)
Code type 0x03 (EFI image)
EFI ROM header contents
EFI Signature 0x0EF1
Compression Type 0x0001 (compressed)
Machine type 0x8664 (X64)
Subsystem 0x000B (EFI boot service driver)
EFI image offset 0x0038 (@0x38)
}}

これはこの OpROM に、オフセット 0x0 のイメージ 1 の、オフセット 0x0038 に圧縮された EFI イメージがあることを示します。

EFI セクションを取得します:

$ dd if=intel_ssd.rom ibs=1 skip=$(( 0x00 + 0x38 )) of=intel_ssd.rom.efi.compressed

バイナリイメージを解凍します:

$ ./BaseTools/Source/C/bin/TianoCompress -d --uefi -v ~/intel_ssd.rom.efi.compressed -o ~/intel_ssd.rom.efi

{{hc|$ file ../intel_ssd.rom.efi|
../intel_ssd.rom.efi: PE32+ executable for EFI (boot service driver), x86-64, 6 sections
}}

{{Pkg|sbsigntools}} で署名を調べると、Microsoft の DB 証明書で署名されていることがわかります:

{{hc|$ sbverify --list ~/intel_ssd.rom.efi|2=
signature 1
image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root
}}

{{Warning|デバイスの文鎮化を回避するために、署名された ROM を搭載したグラフィックカードを使用している場合は、独自のキーを登録した後、セキュアブート DB に必要な発行者が保持されていることを確認してください。}}

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== GRUB で sbctl を使う =====

[[GRUB#セキュアブートサポート]] を見てください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。あるいは、以下のようにすることもできます:

# sbctl verify {{!}} sed -E 's{{!}}^.* (/.+) is not signed${{!}}sbctl sign -s "\1"{{!}}e'

これはファイルパスに依存せず、「✗」文字は必要ありません。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -keyout PK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Platform Key''/" -out PK.crt
$ openssl x509 -outform DER -in PK.crt -out PK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth

"User Mode" で Platform Key を削除できるようにするために空のファイルを署名してください:

$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -keyout KEK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Key Exchange Key''/" -out KEK.crt
$ openssl x509 -outform DER -in KEK.crt -out KEK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth

Signature Database key:

$ openssl req -newkey rsa:4096 -noenc -keyout db.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Signature Database key''/" -out db.crt
$ openssl x509 -outform DER -in db.crt -out db.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/etc/efi-keys/}})、スクリプトを実行してください:

# mkdir /etc/efi-keys
# cd !$
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh
# chmod +x mkkeys.sh
# ./mkkeys.sh
''鍵に埋め込む Common Name を入力 (例: "Secure Boot")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''sbsign'' を使用してください。例えば:

# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key db.key --cert db.crt --output ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/BOOTx64.EFI

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

key=''/path/to/''db.key
cert=''/path/to/''db.crt

if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign "$kernel" --key "$key" --cert "$cert" --output "$kernel"
fi}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ cert-to-efi-sig-list -g "$(< GUID.txt)" ''new_db''.crt ''new_db''.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

db 鍵を置き換えるかわりに Signature Database に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|db}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|loader.efi}} を UEFI によって自動的に起動されるデフォルトのブートローダーの場所にコピーしてください:

# cp /usr/share/preloader-signed/HashTool.efi ''esp''/EFI/BOOT/
# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/BOOT/loader.efi

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI

''shim'' は、MokList に格納されている Machine Owner Key やハッシュによってバイナリを認証することができます。

; Machine Owner Key (MOK): EFI バイナリに署名するためにユーザが生成し利用する鍵
; hash: EFI バイナリの SHA256 ハッシュ

ハッシュを用いるのは単純ですが、ブートローダやカーネルをアップデートするたびに、MokManager 内のそれらのハッシュを追加する必要があります。MOK では鍵を一度追加するだけで済みますが、ブートローダとカーネルをアップデートするたびに、それらに署名する必要があります。

====== shim でハッシュを使う ======

''shim'' は、MokList に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -nodes -keyout MOK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Machine Owner Key''/" -out MOK.crt
$ openssl x509 -outform DER -in MOK.crt -out MOK.cer

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|grubx64.efi}} という名前の) ブートローダーとカーネルに署名:

# sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

key=''/path/to/''MOK.key
cert=''/path/to/''MOK.crt

if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign "$kernel" --key "$key" --cert "$cert" --output "$kernel"
fi}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

{{Expansion|shim を含めるように ISO を再パックするための手順を追加してください。}}

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。以下の手順に従うか、自動化された代替手段として {{AUR|gsai-git}} を使用してください。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI BOOTx64.EFI \
-extract /EFI/BOOT/BOOTIA32.EFI BOOTIA32.EFI \
-extract /shellx64.efi shellx64.efi \
-extract /shellia32.efi shellia32.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ sbsign --key db.key --cert db.crt --output BOOTx64.EFI BOOTx64.EFI
$ sbsign --key db.key --cert db.crt --output BOOTIA32.EFI BOOTIA32.EFI
$ sbsign --key db.key --cert db.crt --output shellx64.efi shellx64.efi
$ sbsign --key db.key --cert db.crt --output shellia32.efi shellia32.efi
$ sbsign --key db.key --cert db.crt --output vmlinuz-linux vmlinuz-linux

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI BOOTIA32.EFI ::/EFI/BOOT/
$ mcopy -D oO -i eltorito_img2_uefi.img shellx64.efi shellia32.efi ::/

変更された El Torito UEFI ブートイメージを使って ISO を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2026-03-12|862815}}

Unified Extensible Firmware Interface/セキュアブート

2026-03-12T02:04:33Z

ELC: TranslationStatus

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[hu:Unified Extensible Firmware Interface (Magyar)/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ([https://gitlab.archlinux.org/archlinux/archiso/-/issues/69 archlinux/archiso#69])。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ The Meaning of all the UEFI Keys] を見てください。

セキュアブートをを使用するには最低でも '''PK''', '''KEK''', '''db''' 鍵が必要です。KEK, db, dbx 証明書は複数追加できますが、Platform Key はひとつしか使えません。

Secure Boot を "User Mode" にすると、上位の鍵を使用してアップデートに署名しないかぎり鍵を更新できなくなります (''sign-efi-sig-list'' を使用)。Platform key は自分自身で署名することができます。

==== OpROM 署名を特定する ====

署名された OpROM があるかどうかを確認するには、次の手順に従います。

OpROM を搭載したすべてのデバイスを一覧表示します:

{{hc|$ find /sys/devices/ -name rom|
/sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
...
}}

これは、署名付き EFI ROM を搭載した Intel DC SSD の例です。デバイスごとに以下の手順を繰り返してください。

{{hc|$ lspci -s 81:00.0|
81:00.0 Non-Volatile memory controller: Intel Corporation PCIe Data Center SSD (rev 01)
}}

ROM をダンプします:

# echo 1 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
# cat /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom > ~/intel_ssd.rom
# echo 0 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom

TianoCore の [https://github.com/tianocore/edk2.git EDK II ツール] 取得してコンパイルします:

$ make -C BaseTools

ROM ファイルを解析します:

{{hc|$ ./BaseTools/Source/C/bin/EfiRom -d ~/intel_ssd.rom|
Image 1 -- Offset 0x0
ROM header contents
Signature 0xAA55
PCIR offset 0x001C
Signature PCIR
Vendor ID 0x8086
Device ID 0x0953
Length 0x001C
Revision 0x0003
DeviceListOffset 0x00
Class Code 0x000000
Image size 0x6A00
Code revision: 0x0000
MaxRuntimeImageLength 0x00
ConfigUtilityCodeHeaderOffset 0x00
DMTFCLPEntryPointOffset 0x00
Indicator 0x80 (last image)
Code type 0x03 (EFI image)
EFI ROM header contents
EFI Signature 0x0EF1
Compression Type 0x0001 (compressed)
Machine type 0x8664 (X64)
Subsystem 0x000B (EFI boot service driver)
EFI image offset 0x0038 (@0x38)
}}

これはこの OpROM に、オフセット 0x0 のイメージ 1 の、オフセット 0x0038 に圧縮された EFI イメージがあることを示します。

EFI セクションを取得します:

$ dd if=intel_ssd.rom ibs=1 skip=$(( 0x00 + 0x38 )) of=intel_ssd.rom.efi.compressed

バイナリイメージを解凍します:

$ ./BaseTools/Source/C/bin/TianoCompress -d --uefi -v ~/intel_ssd.rom.efi.compressed -o ~/intel_ssd.rom.efi

{{hc|$ file ../intel_ssd.rom.efi|
../intel_ssd.rom.efi: PE32+ executable for EFI (boot service driver), x86-64, 6 sections
}}

{{Pkg|sbsigntools}} で署名を調べると、Microsoft の DB 証明書で署名されていることがわかります:

{{hc|$ sbverify --list ~/intel_ssd.rom.efi|2=
signature 1
image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root
}}

{{Warning|デバイスの文鎮化を回避するために、署名された ROM を搭載したグラフィックカードを使用している場合は、独自のキーを登録した後、セキュアブート DB に必要な発行者が保持されていることを確認してください。}}

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== GRUB で sbctl を使う =====

[[GRUB#セキュアブートサポート]] を見てください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。あるいは、以下のようにすることもできます:

# sbctl verify {{!}} sed -E 's{{!}}^.* (/.+) is not signed${{!}}sbctl sign -s "\1"{{!}}e'

これはファイルパスに依存せず、「✗」文字は必要ありません。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -keyout PK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Platform Key''/" -out PK.crt
$ openssl x509 -outform DER -in PK.crt -out PK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth

"User Mode" で Platform Key を削除できるようにするために空のファイルを署名してください:

$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -keyout KEK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Key Exchange Key''/" -out KEK.crt
$ openssl x509 -outform DER -in KEK.crt -out KEK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth

Signature Database key:

$ openssl req -newkey rsa:4096 -noenc -keyout db.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Signature Database key''/" -out db.crt
$ openssl x509 -outform DER -in db.crt -out db.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/etc/efi-keys/}})、スクリプトを実行してください:

# mkdir /etc/efi-keys
# cd !$
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh
# chmod +x mkkeys.sh
# ./mkkeys.sh
''鍵に埋め込む Common Name を入力 (例: "Secure Boot")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''sbsign'' を使用してください。例えば:

# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key db.key --cert db.crt --output ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/BOOTx64.EFI

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

key=''/path/to/''db.key
cert=''/path/to/''db.crt

if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign "$kernel" --key "$key" --cert "$cert" --output "$kernel"
fi}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ cert-to-efi-sig-list -g "$(< GUID.txt)" ''new_db''.crt ''new_db''.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

db 鍵を置き換えるかわりに Signature Database に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|db}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|loader.efi}} を UEFI によって自動的に起動されるデフォルトのブートローダーの場所にコピーしてください:

# cp /usr/share/preloader-signed/HashTool.efi ''esp''/EFI/BOOT/
# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/BOOT/loader.efi

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI

''shim'' は、MokList に格納されている Machine Owner Key やハッシュによってバイナリを認証することができます。

; Machine Owner Key (MOK): EFI バイナリに署名するためにユーザが生成し利用する鍵
; hash: EFI バイナリの SHA256 ハッシュ

ハッシュを用いるのは単純ですが、ブートローダやカーネルをアップデートするたびに、MokManager 内のそれらのハッシュを追加する必要があります。MOK では鍵を一度追加するだけで済みますが、ブートローダとカーネルをアップデートするたびに、それらに署名する必要があります。

====== shim でハッシュを使う ======

''shim'' は、MokList に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -nodes -keyout MOK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Machine Owner Key''/" -out MOK.crt
$ openssl x509 -outform DER -in MOK.crt -out MOK.cer

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|grubx64.efi}} という名前の) ブートローダーとカーネルに署名:

# sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

key=''/path/to/''MOK.key
cert=''/path/to/''MOK.crt

if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign "$kernel" --key "$key" --cert "$cert" --output "$kernel"
fi}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

{{Expansion|shim を含めるように ISO を再パックするための手順を追加してください。}}

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。以下の手順に従うか、自動化された代替手段として {{AUR|gsai-git}} を使用してください。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI BOOTx64.EFI \
-extract /EFI/BOOT/BOOTIA32.EFI BOOTIA32.EFI \
-extract /shellx64.efi shellx64.efi \
-extract /shellia32.efi shellia32.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ sbsign --key db.key --cert db.crt --output BOOTx64.EFI BOOTx64.EFI
$ sbsign --key db.key --cert db.crt --output BOOTIA32.EFI BOOTIA32.EFI
$ sbsign --key db.key --cert db.crt --output shellx64.efi shellx64.efi
$ sbsign --key db.key --cert db.crt --output shellia32.efi shellia32.efi
$ sbsign --key db.key --cert db.crt --output vmlinuz-linux vmlinuz-linux

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI BOOTIA32.EFI ::/EFI/BOOT/
$ mcopy -D oO -i eltorito_img2_uefi.img shellx64.efi shellia32.efi ::/

変更された El Torito UEFI ブートイメージを使って ISO を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2026-03-12|862815}}

Unified Extensible Firmware Interface/セキュアブート

2026-03-12T02:00:47Z

ELC: 重複リンク削除

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[hu:Unified Extensible Firmware Interface (Magyar)/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ([https://gitlab.archlinux.org/archlinux/archiso/-/issues/69 archlinux/archiso#69])。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ The Meaning of all the UEFI Keys] を見てください。

セキュアブートをを使用するには最低でも '''PK''', '''KEK''', '''db''' 鍵が必要です。KEK, db, dbx 証明書は複数追加できますが、Platform Key はひとつしか使えません。

Secure Boot を "User Mode" にすると、上位の鍵を使用してアップデートに署名しないかぎり鍵を更新できなくなります (''sign-efi-sig-list'' を使用)。Platform key は自分自身で署名することができます。

==== OpROM 署名を特定する ====

署名された OpROM があるかどうかを確認するには、次の手順に従います。

OpROM を搭載したすべてのデバイスを一覧表示します:

{{hc|$ find /sys/devices/ -name rom|
/sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
...
}}

これは、署名付き EFI ROM を搭載した Intel DC SSD の例です。デバイスごとに以下の手順を繰り返してください。

{{hc|$ lspci -s 81:00.0|
81:00.0 Non-Volatile memory controller: Intel Corporation PCIe Data Center SSD (rev 01)
}}

ROM をダンプします:

# echo 1 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
# cat /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom > ~/intel_ssd.rom
# echo 0 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom

TianoCore の [https://github.com/tianocore/edk2.git EDK II ツール] 取得してコンパイルします:

$ make -C BaseTools

ROM ファイルを解析します:

{{hc|$ ./BaseTools/Source/C/bin/EfiRom -d ~/intel_ssd.rom|
Image 1 -- Offset 0x0
ROM header contents
Signature 0xAA55
PCIR offset 0x001C
Signature PCIR
Vendor ID 0x8086
Device ID 0x0953
Length 0x001C
Revision 0x0003
DeviceListOffset 0x00
Class Code 0x000000
Image size 0x6A00
Code revision: 0x0000
MaxRuntimeImageLength 0x00
ConfigUtilityCodeHeaderOffset 0x00
DMTFCLPEntryPointOffset 0x00
Indicator 0x80 (last image)
Code type 0x03 (EFI image)
EFI ROM header contents
EFI Signature 0x0EF1
Compression Type 0x0001 (compressed)
Machine type 0x8664 (X64)
Subsystem 0x000B (EFI boot service driver)
EFI image offset 0x0038 (@0x38)
}}

これはこの OpROM に、オフセット 0x0 のイメージ 1 の、オフセット 0x0038 に圧縮された EFI イメージがあることを示します。

EFI セクションを取得します:

$ dd if=intel_ssd.rom ibs=1 skip=$(( 0x00 + 0x38 )) of=intel_ssd.rom.efi.compressed

バイナリイメージを解凍します:

$ ./BaseTools/Source/C/bin/TianoCompress -d --uefi -v ~/intel_ssd.rom.efi.compressed -o ~/intel_ssd.rom.efi

{{hc|$ file ../intel_ssd.rom.efi|
../intel_ssd.rom.efi: PE32+ executable for EFI (boot service driver), x86-64, 6 sections
}}

{{Pkg|sbsigntools}} で署名を調べると、Microsoft の DB 証明書で署名されていることがわかります:

{{hc|$ sbverify --list ~/intel_ssd.rom.efi|2=
signature 1
image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root
}}

{{Warning|デバイスの文鎮化を回避するために、署名された ROM を搭載したグラフィックカードを使用している場合は、独自のキーを登録した後、セキュアブート DB に必要な発行者が保持されていることを確認してください。}}

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== GRUB で sbctl を使う =====

[[GRUB#セキュアブートサポート]] を見てください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。あるいは、以下のようにすることもできます:

# sbctl verify {{!}} sed -E 's{{!}}^.* (/.+) is not signed${{!}}sbctl sign -s "\1"{{!}}e'

これはファイルパスに依存せず、「✗」文字は必要ありません。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -keyout PK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Platform Key''/" -out PK.crt
$ openssl x509 -outform DER -in PK.crt -out PK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth

"User Mode" で Platform Key を削除できるようにするために空のファイルを署名してください:

$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -keyout KEK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Key Exchange Key''/" -out KEK.crt
$ openssl x509 -outform DER -in KEK.crt -out KEK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth

Signature Database key:

$ openssl req -newkey rsa:4096 -noenc -keyout db.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Signature Database key''/" -out db.crt
$ openssl x509 -outform DER -in db.crt -out db.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/etc/efi-keys/}})、スクリプトを実行してください:

# mkdir /etc/efi-keys
# cd !$
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh
# chmod +x mkkeys.sh
# ./mkkeys.sh
''鍵に埋め込む Common Name を入力 (例: "Secure Boot")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''sbsign'' を使用してください。例えば:

# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key db.key --cert db.crt --output ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/BOOTx64.EFI

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

key=''/path/to/''db.key
cert=''/path/to/''db.crt

if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign "$kernel" --key "$key" --cert "$cert" --output "$kernel"
fi}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ cert-to-efi-sig-list -g "$(< GUID.txt)" ''new_db''.crt ''new_db''.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

db 鍵を置き換えるかわりに Signature Database に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|db}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|loader.efi}} を UEFI によって自動的に起動されるデフォルトのブートローダーの場所にコピーしてください:

# cp /usr/share/preloader-signed/HashTool.efi ''esp''/EFI/BOOT/
# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/BOOT/loader.efi

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI

''shim'' は、MokList に格納されている Machine Owner Key やハッシュによってバイナリを認証することができます。

; Machine Owner Key (MOK): EFI バイナリに署名するためにユーザが生成し利用する鍵
; hash: EFI バイナリの SHA256 ハッシュ

ハッシュを用いるのは単純ですが、ブートローダやカーネルをアップデートするたびに、MokManager 内のそれらのハッシュを追加する必要があります。MOK では鍵を一度追加するだけで済みますが、ブートローダとカーネルをアップデートするたびに、それらに署名する必要があります。

====== shim でハッシュを使う ======

''shim'' は、MokList に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -nodes -keyout MOK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Machine Owner Key''/" -out MOK.crt
$ openssl x509 -outform DER -in MOK.crt -out MOK.cer

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|grubx64.efi}} という名前の) ブートローダーとカーネルに署名:

# sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

key=''/path/to/''MOK.key
cert=''/path/to/''MOK.crt

if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign "$kernel" --key "$key" --cert "$cert" --output "$kernel"
fi}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

{{Expansion|shim を含めるように ISO を再パックするための手順を追加してください。}}

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。以下の手順に従うか、自動化された代替手段として {{AUR|gsai-git}} を使用してください。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI BOOTx64.EFI \
-extract /EFI/BOOT/BOOTIA32.EFI BOOTIA32.EFI \
-extract /shellx64.efi shellx64.efi \
-extract /shellia32.efi shellia32.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ sbsign --key db.key --cert db.crt --output BOOTx64.EFI BOOTx64.EFI
$ sbsign --key db.key --cert db.crt --output BOOTIA32.EFI BOOTIA32.EFI
$ sbsign --key db.key --cert db.crt --output shellx64.efi shellx64.efi
$ sbsign --key db.key --cert db.crt --output shellia32.efi shellia32.efi
$ sbsign --key db.key --cert db.crt --output vmlinuz-linux vmlinuz-linux

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI BOOTIA32.EFI ::/EFI/BOOT/
$ mcopy -D oO -i eltorito_img2_uefi.img shellx64.efi shellia32.efi ::/

変更された El Torito UEFI ブートイメージを使って ISO を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2025-10-29|850808}}

Unified Extensible Firmware Interface/セキュアブート

2026-03-12T01:50:03Z

ELC: /* shim で鍵を使う */ kernel-sbsign スクリプトを簡略化

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[hu:Unified Extensible Firmware Interface (Magyar)/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ([https://gitlab.archlinux.org/archlinux/archiso/-/issues/69 archlinux/archiso#69])。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ The Meaning of all the UEFI Keys] を見てください。

セキュアブートをを使用するには最低でも '''PK''', '''KEK''', '''db''' 鍵が必要です。KEK, db, dbx 証明書は複数追加できますが、Platform Key はひとつしか使えません。

Secure Boot を "User Mode" にすると、上位の鍵を使用してアップデートに署名しないかぎり鍵を更新できなくなります (''sign-efi-sig-list'' を使用)。Platform key は自分自身で署名することができます。

==== OpROM 署名を特定する ====

署名された OpROM があるかどうかを確認するには、次の手順に従います。

OpROM を搭載したすべてのデバイスを一覧表示します:

{{hc|$ find /sys/devices/ -name rom|
/sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
...
}}

これは、署名付き EFI ROM を搭載した Intel DC SSD の例です。デバイスごとに以下の手順を繰り返してください。

{{hc|$ lspci -s 81:00.0|
81:00.0 Non-Volatile memory controller: Intel Corporation PCIe Data Center SSD (rev 01)
}}

ROM をダンプします:

# echo 1 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
# cat /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom > ~/intel_ssd.rom
# echo 0 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom

TianoCore の [https://github.com/tianocore/edk2.git EDK II ツール] 取得してコンパイルします:

$ make -C BaseTools

ROM ファイルを解析します:

{{hc|$ ./BaseTools/Source/C/bin/EfiRom -d ~/intel_ssd.rom|
Image 1 -- Offset 0x0
ROM header contents
Signature 0xAA55
PCIR offset 0x001C
Signature PCIR
Vendor ID 0x8086
Device ID 0x0953
Length 0x001C
Revision 0x0003
DeviceListOffset 0x00
Class Code 0x000000
Image size 0x6A00
Code revision: 0x0000
MaxRuntimeImageLength 0x00
ConfigUtilityCodeHeaderOffset 0x00
DMTFCLPEntryPointOffset 0x00
Indicator 0x80 (last image)
Code type 0x03 (EFI image)
EFI ROM header contents
EFI Signature 0x0EF1
Compression Type 0x0001 (compressed)
Machine type 0x8664 (X64)
Subsystem 0x000B (EFI boot service driver)
EFI image offset 0x0038 (@0x38)
}}

これはこの OpROM に、オフセット 0x0 のイメージ 1 の、オフセット 0x0038 に圧縮された EFI イメージがあることを示します。

EFI セクションを取得します:

$ dd if=intel_ssd.rom ibs=1 skip=$(( 0x00 + 0x38 )) of=intel_ssd.rom.efi.compressed

バイナリイメージを解凍します:

$ ./BaseTools/Source/C/bin/TianoCompress -d --uefi -v ~/intel_ssd.rom.efi.compressed -o ~/intel_ssd.rom.efi

{{hc|$ file ../intel_ssd.rom.efi|
../intel_ssd.rom.efi: PE32+ executable for EFI (boot service driver), x86-64, 6 sections
}}

{{Pkg|sbsigntools}} で署名を調べると、Microsoft の DB 証明書で署名されていることがわかります:

{{hc|$ sbverify --list ~/intel_ssd.rom.efi|2=
signature 1
image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root
}}

{{Warning|デバイスの文鎮化を回避するために、署名された ROM を搭載したグラフィックカードを使用している場合は、独自のキーを登録した後、セキュアブート DB に必要な発行者が保持されていることを確認してください。}}

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== GRUB で sbctl を使う =====

[[GRUB#セキュアブートサポート]] を見てください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。あるいは、以下のようにすることもできます:

# sbctl verify {{!}} sed -E 's{{!}}^.* (/.+) is not signed${{!}}sbctl sign -s "\1"{{!}}e'

これはファイルパスに依存せず、「✗」文字は必要ありません。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -keyout PK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Platform Key''/" -out PK.crt
$ openssl x509 -outform DER -in PK.crt -out PK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth

"User Mode" で Platform Key を削除できるようにするために空のファイルを署名してください:

$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -keyout KEK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Key Exchange Key''/" -out KEK.crt
$ openssl x509 -outform DER -in KEK.crt -out KEK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth

Signature Database key:

$ openssl req -newkey rsa:4096 -noenc -keyout db.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Signature Database key''/" -out db.crt
$ openssl x509 -outform DER -in db.crt -out db.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/etc/efi-keys/}})、スクリプトを実行してください:

# mkdir /etc/efi-keys
# cd !$
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh
# chmod +x mkkeys.sh
# ./mkkeys.sh
''鍵に埋め込む Common Name を入力 (例: "Secure Boot")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''sbsign'' を使用してください。例えば:

# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key db.key --cert db.crt --output ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/BOOTx64.EFI

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

key=''/path/to/''db.key
cert=''/path/to/''db.crt

if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign "$kernel" --key "$key" --cert "$cert" --output "$kernel"
fi}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ cert-to-efi-sig-list -g "$(< GUID.txt)" ''new_db''.crt ''new_db''.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

db 鍵を置き換えるかわりに Signature Database に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|db}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|loader.efi}} を UEFI によって自動的に起動されるデフォルトのブートローダーの場所にコピーしてください:

# cp /usr/share/preloader-signed/HashTool.efi ''esp''/EFI/BOOT/
# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/BOOT/loader.efi

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI

''shim'' は、MokList に格納されている Machine Owner Key やハッシュによってバイナリを認証することができます。

; Machine Owner Key (MOK): EFI バイナリに署名するためにユーザが生成し利用する鍵
; hash: EFI バイナリの SHA256 ハッシュ

ハッシュを用いるのは単純ですが、ブートローダやカーネルをアップデートするたびに、MokManager 内のそれらのハッシュを追加する必要があります。MOK では鍵を一度追加するだけで済みますが、ブートローダとカーネルをアップデートするたびに、それらに署名する必要があります。

====== shim でハッシュを使う ======

''shim'' は、MokList に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -nodes -keyout MOK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Machine Owner Key''/" -out MOK.crt
$ openssl x509 -outform DER -in MOK.crt -out MOK.cer

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|grubx64.efi}} という名前の) ブートローダーとカーネルに署名:

# sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

key=''/path/to/''MOK.key
cert=''/path/to/''MOK.crt

if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign "$kernel" --key "$key" --cert "$cert" --output "$kernel"
fi}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

{{Expansion|shim を含めるように ISO を再パックするための手順を追加してください。}}

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。以下の手順に従うか、自動化された代替手段として {{AUR|gsai-git}} を使用してください。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI BOOTx64.EFI \
-extract /EFI/BOOT/BOOTIA32.EFI BOOTIA32.EFI \
-extract /shellx64.efi shellx64.efi \
-extract /shellia32.efi shellia32.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ sbsign --key db.key --cert db.crt --output BOOTx64.EFI BOOTx64.EFI
$ sbsign --key db.key --cert db.crt --output BOOTIA32.EFI BOOTIA32.EFI
$ sbsign --key db.key --cert db.crt --output shellx64.efi shellx64.efi
$ sbsign --key db.key --cert db.crt --output shellia32.efi shellia32.efi
$ sbsign --key db.key --cert db.crt --output vmlinuz-linux vmlinuz-linux

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI BOOTIA32.EFI ::/EFI/BOOT/
$ mcopy -D oO -i eltorito_img2_uefi.img shellx64.efi shellia32.efi ::/

変更された El Torito UEFI ブートイメージを使って ISO を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2025-10-29|850808}}

Unified Extensible Firmware Interface/セキュアブート

2026-03-12T01:48:01Z

ELC: /* mkinitcpio のポストフックでカーネルに署名する */ kernel-sbsign スクリプトを簡略化

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[hu:Unified Extensible Firmware Interface (Magyar)/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ([https://gitlab.archlinux.org/archlinux/archiso/-/issues/69 archlinux/archiso#69])。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ The Meaning of all the UEFI Keys] を見てください。

セキュアブートをを使用するには最低でも '''PK''', '''KEK''', '''db''' 鍵が必要です。KEK, db, dbx 証明書は複数追加できますが、Platform Key はひとつしか使えません。

Secure Boot を "User Mode" にすると、上位の鍵を使用してアップデートに署名しないかぎり鍵を更新できなくなります (''sign-efi-sig-list'' を使用)。Platform key は自分自身で署名することができます。

==== OpROM 署名を特定する ====

署名された OpROM があるかどうかを確認するには、次の手順に従います。

OpROM を搭載したすべてのデバイスを一覧表示します:

{{hc|$ find /sys/devices/ -name rom|
/sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
...
}}

これは、署名付き EFI ROM を搭載した Intel DC SSD の例です。デバイスごとに以下の手順を繰り返してください。

{{hc|$ lspci -s 81:00.0|
81:00.0 Non-Volatile memory controller: Intel Corporation PCIe Data Center SSD (rev 01)
}}

ROM をダンプします:

# echo 1 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
# cat /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom > ~/intel_ssd.rom
# echo 0 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom

TianoCore の [https://github.com/tianocore/edk2.git EDK II ツール] 取得してコンパイルします:

$ make -C BaseTools

ROM ファイルを解析します:

{{hc|$ ./BaseTools/Source/C/bin/EfiRom -d ~/intel_ssd.rom|
Image 1 -- Offset 0x0
ROM header contents
Signature 0xAA55
PCIR offset 0x001C
Signature PCIR
Vendor ID 0x8086
Device ID 0x0953
Length 0x001C
Revision 0x0003
DeviceListOffset 0x00
Class Code 0x000000
Image size 0x6A00
Code revision: 0x0000
MaxRuntimeImageLength 0x00
ConfigUtilityCodeHeaderOffset 0x00
DMTFCLPEntryPointOffset 0x00
Indicator 0x80 (last image)
Code type 0x03 (EFI image)
EFI ROM header contents
EFI Signature 0x0EF1
Compression Type 0x0001 (compressed)
Machine type 0x8664 (X64)
Subsystem 0x000B (EFI boot service driver)
EFI image offset 0x0038 (@0x38)
}}

これはこの OpROM に、オフセット 0x0 のイメージ 1 の、オフセット 0x0038 に圧縮された EFI イメージがあることを示します。

EFI セクションを取得します:

$ dd if=intel_ssd.rom ibs=1 skip=$(( 0x00 + 0x38 )) of=intel_ssd.rom.efi.compressed

バイナリイメージを解凍します:

$ ./BaseTools/Source/C/bin/TianoCompress -d --uefi -v ~/intel_ssd.rom.efi.compressed -o ~/intel_ssd.rom.efi

{{hc|$ file ../intel_ssd.rom.efi|
../intel_ssd.rom.efi: PE32+ executable for EFI (boot service driver), x86-64, 6 sections
}}

{{Pkg|sbsigntools}} で署名を調べると、Microsoft の DB 証明書で署名されていることがわかります:

{{hc|$ sbverify --list ~/intel_ssd.rom.efi|2=
signature 1
image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root
}}

{{Warning|デバイスの文鎮化を回避するために、署名された ROM を搭載したグラフィックカードを使用している場合は、独自のキーを登録した後、セキュアブート DB に必要な発行者が保持されていることを確認してください。}}

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== GRUB で sbctl を使う =====

[[GRUB#セキュアブートサポート]] を見てください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。あるいは、以下のようにすることもできます:

# sbctl verify {{!}} sed -E 's{{!}}^.* (/.+) is not signed${{!}}sbctl sign -s "\1"{{!}}e'

これはファイルパスに依存せず、「✗」文字は必要ありません。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -keyout PK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Platform Key''/" -out PK.crt
$ openssl x509 -outform DER -in PK.crt -out PK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth

"User Mode" で Platform Key を削除できるようにするために空のファイルを署名してください:

$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -keyout KEK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Key Exchange Key''/" -out KEK.crt
$ openssl x509 -outform DER -in KEK.crt -out KEK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth

Signature Database key:

$ openssl req -newkey rsa:4096 -noenc -keyout db.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Signature Database key''/" -out db.crt
$ openssl x509 -outform DER -in db.crt -out db.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/etc/efi-keys/}})、スクリプトを実行してください:

# mkdir /etc/efi-keys
# cd !$
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh
# chmod +x mkkeys.sh
# ./mkkeys.sh
''鍵に埋め込む Common Name を入力 (例: "Secure Boot")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''sbsign'' を使用してください。例えば:

# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key db.key --cert db.crt --output ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/BOOTx64.EFI

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

key=''/path/to/''db.key
cert=''/path/to/''db.crt

if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign "$kernel" --key "$key" --cert "$cert" --output "$kernel"
fi}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ cert-to-efi-sig-list -g "$(< GUID.txt)" ''new_db''.crt ''new_db''.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

db 鍵を置き換えるかわりに Signature Database に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|db}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|loader.efi}} を UEFI によって自動的に起動されるデフォルトのブートローダーの場所にコピーしてください:

# cp /usr/share/preloader-signed/HashTool.efi ''esp''/EFI/BOOT/
# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/BOOT/loader.efi

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI

''shim'' は、MokList に格納されている Machine Owner Key やハッシュによってバイナリを認証することができます。

; Machine Owner Key (MOK): EFI バイナリに署名するためにユーザが生成し利用する鍵
; hash: EFI バイナリの SHA256 ハッシュ

ハッシュを用いるのは単純ですが、ブートローダやカーネルをアップデートするたびに、MokManager 内のそれらのハッシュを追加する必要があります。MOK では鍵を一度追加するだけで済みますが、ブートローダとカーネルをアップデートするたびに、それらに署名する必要があります。

====== shim でハッシュを使う ======

''shim'' は、MokList に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -nodes -keyout MOK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Machine Owner Key''/" -out MOK.crt
$ openssl x509 -outform DER -in MOK.crt -out MOK.cer

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|grubx64.efi}} という名前の) ブートローダーとカーネルに署名:

# sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

{{Expansion|shim を含めるように ISO を再パックするための手順を追加してください。}}

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。以下の手順に従うか、自動化された代替手段として {{AUR|gsai-git}} を使用してください。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI BOOTx64.EFI \
-extract /EFI/BOOT/BOOTIA32.EFI BOOTIA32.EFI \
-extract /shellx64.efi shellx64.efi \
-extract /shellia32.efi shellia32.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ sbsign --key db.key --cert db.crt --output BOOTx64.EFI BOOTx64.EFI
$ sbsign --key db.key --cert db.crt --output BOOTIA32.EFI BOOTIA32.EFI
$ sbsign --key db.key --cert db.crt --output shellx64.efi shellx64.efi
$ sbsign --key db.key --cert db.crt --output shellia32.efi shellia32.efi
$ sbsign --key db.key --cert db.crt --output vmlinuz-linux vmlinuz-linux

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI BOOTIA32.EFI ::/EFI/BOOT/
$ mcopy -D oO -i eltorito_img2_uefi.img shellx64.efi shellia32.efi ::/

変更された El Torito UEFI ブートイメージを使って ISO を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2025-10-29|850808}}

Unified Extensible Firmware Interface/セキュアブート

2026-03-12T01:13:55Z

ELC: /* 公式の ISO をカスタムの鍵で署名する */ AURからgsaiを追加

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[hu:Unified Extensible Firmware Interface (Magyar)/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ([https://gitlab.archlinux.org/archlinux/archiso/-/issues/69 archlinux/archiso#69])。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ The Meaning of all the UEFI Keys] を見てください。

セキュアブートをを使用するには最低でも '''PK''', '''KEK''', '''db''' 鍵が必要です。KEK, db, dbx 証明書は複数追加できますが、Platform Key はひとつしか使えません。

Secure Boot を "User Mode" にすると、上位の鍵を使用してアップデートに署名しないかぎり鍵を更新できなくなります (''sign-efi-sig-list'' を使用)。Platform key は自分自身で署名することができます。

==== OpROM 署名を特定する ====

署名された OpROM があるかどうかを確認するには、次の手順に従います。

OpROM を搭載したすべてのデバイスを一覧表示します:

{{hc|$ find /sys/devices/ -name rom|
/sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
...
}}

これは、署名付き EFI ROM を搭載した Intel DC SSD の例です。デバイスごとに以下の手順を繰り返してください。

{{hc|$ lspci -s 81:00.0|
81:00.0 Non-Volatile memory controller: Intel Corporation PCIe Data Center SSD (rev 01)
}}

ROM をダンプします:

# echo 1 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
# cat /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom > ~/intel_ssd.rom
# echo 0 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom

TianoCore の [https://github.com/tianocore/edk2.git EDK II ツール] 取得してコンパイルします:

$ make -C BaseTools

ROM ファイルを解析します:

{{hc|$ ./BaseTools/Source/C/bin/EfiRom -d ~/intel_ssd.rom|
Image 1 -- Offset 0x0
ROM header contents
Signature 0xAA55
PCIR offset 0x001C
Signature PCIR
Vendor ID 0x8086
Device ID 0x0953
Length 0x001C
Revision 0x0003
DeviceListOffset 0x00
Class Code 0x000000
Image size 0x6A00
Code revision: 0x0000
MaxRuntimeImageLength 0x00
ConfigUtilityCodeHeaderOffset 0x00
DMTFCLPEntryPointOffset 0x00
Indicator 0x80 (last image)
Code type 0x03 (EFI image)
EFI ROM header contents
EFI Signature 0x0EF1
Compression Type 0x0001 (compressed)
Machine type 0x8664 (X64)
Subsystem 0x000B (EFI boot service driver)
EFI image offset 0x0038 (@0x38)
}}

これはこの OpROM に、オフセット 0x0 のイメージ 1 の、オフセット 0x0038 に圧縮された EFI イメージがあることを示します。

EFI セクションを取得します:

$ dd if=intel_ssd.rom ibs=1 skip=$(( 0x00 + 0x38 )) of=intel_ssd.rom.efi.compressed

バイナリイメージを解凍します:

$ ./BaseTools/Source/C/bin/TianoCompress -d --uefi -v ~/intel_ssd.rom.efi.compressed -o ~/intel_ssd.rom.efi

{{hc|$ file ../intel_ssd.rom.efi|
../intel_ssd.rom.efi: PE32+ executable for EFI (boot service driver), x86-64, 6 sections
}}

{{Pkg|sbsigntools}} で署名を調べると、Microsoft の DB 証明書で署名されていることがわかります:

{{hc|$ sbverify --list ~/intel_ssd.rom.efi|2=
signature 1
image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root
}}

{{Warning|デバイスの文鎮化を回避するために、署名された ROM を搭載したグラフィックカードを使用している場合は、独自のキーを登録した後、セキュアブート DB に必要な発行者が保持されていることを確認してください。}}

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== GRUB で sbctl を使う =====

[[GRUB#セキュアブートサポート]] を見てください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。あるいは、以下のようにすることもできます:

# sbctl verify {{!}} sed -E 's{{!}}^.* (/.+) is not signed${{!}}sbctl sign -s "\1"{{!}}e'

これはファイルパスに依存せず、「✗」文字は必要ありません。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -keyout PK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Platform Key''/" -out PK.crt
$ openssl x509 -outform DER -in PK.crt -out PK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth

"User Mode" で Platform Key を削除できるようにするために空のファイルを署名してください:

$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -keyout KEK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Key Exchange Key''/" -out KEK.crt
$ openssl x509 -outform DER -in KEK.crt -out KEK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth

Signature Database key:

$ openssl req -newkey rsa:4096 -noenc -keyout db.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Signature Database key''/" -out db.crt
$ openssl x509 -outform DER -in db.crt -out db.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/etc/efi-keys/}})、スクリプトを実行してください:

# mkdir /etc/efi-keys
# cd !$
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh
# chmod +x mkkeys.sh
# ./mkkeys.sh
''鍵に埋め込む Common Name を入力 (例: "Secure Boot")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''sbsign'' を使用してください。例えば:

# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key db.key --cert db.crt --output ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/BOOTx64.EFI

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ cert-to-efi-sig-list -g "$(< GUID.txt)" ''new_db''.crt ''new_db''.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

db 鍵を置き換えるかわりに Signature Database に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|db}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|loader.efi}} を UEFI によって自動的に起動されるデフォルトのブートローダーの場所にコピーしてください:

# cp /usr/share/preloader-signed/HashTool.efi ''esp''/EFI/BOOT/
# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/BOOT/loader.efi

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI

''shim'' は、MokList に格納されている Machine Owner Key やハッシュによってバイナリを認証することができます。

; Machine Owner Key (MOK): EFI バイナリに署名するためにユーザが生成し利用する鍵
; hash: EFI バイナリの SHA256 ハッシュ

ハッシュを用いるのは単純ですが、ブートローダやカーネルをアップデートするたびに、MokManager 内のそれらのハッシュを追加する必要があります。MOK では鍵を一度追加するだけで済みますが、ブートローダとカーネルをアップデートするたびに、それらに署名する必要があります。

====== shim でハッシュを使う ======

''shim'' は、MokList に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -nodes -keyout MOK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Machine Owner Key''/" -out MOK.crt
$ openssl x509 -outform DER -in MOK.crt -out MOK.cer

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|grubx64.efi}} という名前の) ブートローダーとカーネルに署名:

# sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

{{Expansion|shim を含めるように ISO を再パックするための手順を追加してください。}}

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。以下の手順に従うか、自動化された代替手段として {{AUR|gsai-git}} を使用してください。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI BOOTx64.EFI \
-extract /EFI/BOOT/BOOTIA32.EFI BOOTIA32.EFI \
-extract /shellx64.efi shellx64.efi \
-extract /shellia32.efi shellia32.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ sbsign --key db.key --cert db.crt --output BOOTx64.EFI BOOTx64.EFI
$ sbsign --key db.key --cert db.crt --output BOOTIA32.EFI BOOTIA32.EFI
$ sbsign --key db.key --cert db.crt --output shellx64.efi shellx64.efi
$ sbsign --key db.key --cert db.crt --output shellia32.efi shellia32.efi
$ sbsign --key db.key --cert db.crt --output vmlinuz-linux vmlinuz-linux

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI BOOTIA32.EFI ::/EFI/BOOT/
$ mcopy -D oO -i eltorito_img2_uefi.img shellx64.efi shellia32.efi ::/

変更された El Torito UEFI ブートイメージを使って ISO を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2025-10-29|850808}}

Unified Extensible Firmware Interface/セキュアブート

2026-03-12T01:03:22Z

ELC: /* OpROM 署名を特定する */ 追加

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[hu:Unified Extensible Firmware Interface (Magyar)/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ([https://gitlab.archlinux.org/archlinux/archiso/-/issues/69 archlinux/archiso#69])。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ The Meaning of all the UEFI Keys] を見てください。

セキュアブートをを使用するには最低でも '''PK''', '''KEK''', '''db''' 鍵が必要です。KEK, db, dbx 証明書は複数追加できますが、Platform Key はひとつしか使えません。

Secure Boot を "User Mode" にすると、上位の鍵を使用してアップデートに署名しないかぎり鍵を更新できなくなります (''sign-efi-sig-list'' を使用)。Platform key は自分自身で署名することができます。

==== OpROM 署名を特定する ====

署名された OpROM があるかどうかを確認するには、次の手順に従います。

OpROM を搭載したすべてのデバイスを一覧表示します:

{{hc|$ find /sys/devices/ -name rom|
/sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
...
}}

これは、署名付き EFI ROM を搭載した Intel DC SSD の例です。デバイスごとに以下の手順を繰り返してください。

{{hc|$ lspci -s 81:00.0|
81:00.0 Non-Volatile memory controller: Intel Corporation PCIe Data Center SSD (rev 01)
}}

ROM をダンプします:

# echo 1 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom
# cat /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom > ~/intel_ssd.rom
# echo 0 > /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/rom

TianoCore の [https://github.com/tianocore/edk2.git EDK II ツール] 取得してコンパイルします:

$ make -C BaseTools

ROM ファイルを解析します:

{{hc|$ ./BaseTools/Source/C/bin/EfiRom -d ~/intel_ssd.rom|
Image 1 -- Offset 0x0
ROM header contents
Signature 0xAA55
PCIR offset 0x001C
Signature PCIR
Vendor ID 0x8086
Device ID 0x0953
Length 0x001C
Revision 0x0003
DeviceListOffset 0x00
Class Code 0x000000
Image size 0x6A00
Code revision: 0x0000
MaxRuntimeImageLength 0x00
ConfigUtilityCodeHeaderOffset 0x00
DMTFCLPEntryPointOffset 0x00
Indicator 0x80 (last image)
Code type 0x03 (EFI image)
EFI ROM header contents
EFI Signature 0x0EF1
Compression Type 0x0001 (compressed)
Machine type 0x8664 (X64)
Subsystem 0x000B (EFI boot service driver)
EFI image offset 0x0038 (@0x38)
}}

これはこの OpROM に、オフセット 0x0 のイメージ 1 の、オフセット 0x0038 に圧縮された EFI イメージがあることを示します。

EFI セクションを取得します:

$ dd if=intel_ssd.rom ibs=1 skip=$(( 0x00 + 0x38 )) of=intel_ssd.rom.efi.compressed

バイナリイメージを解凍します:

$ ./BaseTools/Source/C/bin/TianoCompress -d --uefi -v ~/intel_ssd.rom.efi.compressed -o ~/intel_ssd.rom.efi

{{hc|$ file ../intel_ssd.rom.efi|
../intel_ssd.rom.efi: PE32+ executable for EFI (boot service driver), x86-64, 6 sections
}}

{{Pkg|sbsigntools}} で署名を調べると、Microsoft の DB 証明書で署名されていることがわかります:

{{hc|$ sbverify --list ~/intel_ssd.rom.efi|2=
signature 1
image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root
}}

{{Warning|デバイスの文鎮化を回避するために、署名された ROM を搭載したグラフィックカードを使用している場合は、独自のキーを登録した後、セキュアブート DB に必要な発行者が保持されていることを確認してください。}}

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== GRUB で sbctl を使う =====

[[GRUB#セキュアブートサポート]] を見てください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。あるいは、以下のようにすることもできます:

# sbctl verify {{!}} sed -E 's{{!}}^.* (/.+) is not signed${{!}}sbctl sign -s "\1"{{!}}e'

これはファイルパスに依存せず、「✗」文字は必要ありません。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -keyout PK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Platform Key''/" -out PK.crt
$ openssl x509 -outform DER -in PK.crt -out PK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth

"User Mode" で Platform Key を削除できるようにするために空のファイルを署名してください:

$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -keyout KEK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Key Exchange Key''/" -out KEK.crt
$ openssl x509 -outform DER -in KEK.crt -out KEK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth

Signature Database key:

$ openssl req -newkey rsa:4096 -noenc -keyout db.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Signature Database key''/" -out db.crt
$ openssl x509 -outform DER -in db.crt -out db.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/etc/efi-keys/}})、スクリプトを実行してください:

# mkdir /etc/efi-keys
# cd !$
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh
# chmod +x mkkeys.sh
# ./mkkeys.sh
''鍵に埋め込む Common Name を入力 (例: "Secure Boot")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''sbsign'' を使用してください。例えば:

# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key db.key --cert db.crt --output ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/BOOTx64.EFI

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ cert-to-efi-sig-list -g "$(< GUID.txt)" ''new_db''.crt ''new_db''.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

db 鍵を置き換えるかわりに Signature Database に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|db}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|loader.efi}} を UEFI によって自動的に起動されるデフォルトのブートローダーの場所にコピーしてください:

# cp /usr/share/preloader-signed/HashTool.efi ''esp''/EFI/BOOT/
# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/BOOT/loader.efi

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI

''shim'' は、MokList に格納されている Machine Owner Key やハッシュによってバイナリを認証することができます。

; Machine Owner Key (MOK): EFI バイナリに署名するためにユーザが生成し利用する鍵
; hash: EFI バイナリの SHA256 ハッシュ

ハッシュを用いるのは単純ですが、ブートローダやカーネルをアップデートするたびに、MokManager 内のそれらのハッシュを追加する必要があります。MOK では鍵を一度追加するだけで済みますが、ブートローダとカーネルをアップデートするたびに、それらに署名する必要があります。

====== shim でハッシュを使う ======

''shim'' は、MokList に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -nodes -keyout MOK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Machine Owner Key''/" -out MOK.crt
$ openssl x509 -outform DER -in MOK.crt -out MOK.cer

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|grubx64.efi}} という名前の) ブートローダーとカーネルに署名:

# sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

{{Expansion|shim を含めるように ISO を再パックするための手順を追加してください。}}

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI BOOTx64.EFI \
-extract /EFI/BOOT/BOOTIA32.EFI BOOTIA32.EFI \
-extract /shellx64.efi shellx64.efi \
-extract /shellia32.efi shellia32.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ sbsign --key db.key --cert db.crt --output BOOTx64.EFI BOOTx64.EFI
$ sbsign --key db.key --cert db.crt --output BOOTIA32.EFI BOOTIA32.EFI
$ sbsign --key db.key --cert db.crt --output shellx64.efi shellx64.efi
$ sbsign --key db.key --cert db.crt --output shellia32.efi shellia32.efi
$ sbsign --key db.key --cert db.crt --output vmlinuz-linux vmlinuz-linux

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI BOOTIA32.EFI ::/EFI/BOOT/
$ mcopy -D oO -i eltorito_img2_uefi.img shellx64.efi shellia32.efi ::/

変更された El Torito UEFI ブートイメージを使って ISO を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2025-10-29|850808}}

Unified Extensible Firmware Interface/セキュアブート

2026-03-12T00:44:34Z

ELC: /* GRUB で sbctl を使う */ 追加

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[hu:Unified Extensible Firmware Interface (Magyar)/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ([https://gitlab.archlinux.org/archlinux/archiso/-/issues/69 archlinux/archiso#69])。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ The Meaning of all the UEFI Keys] を見てください。

セキュアブートをを使用するには最低でも '''PK''', '''KEK''', '''db''' 鍵が必要です。KEK, db, dbx 証明書は複数追加できますが、Platform Key はひとつしか使えません。

Secure Boot を "User Mode" にすると、上位の鍵を使用してアップデートに署名しないかぎり鍵を更新できなくなります (''sign-efi-sig-list'' を使用)。Platform key は自分自身で署名することができます。

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== GRUB で sbctl を使う =====

[[GRUB#セキュアブートサポート]] を見てください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。あるいは、以下のようにすることもできます:

# sbctl verify {{!}} sed -E 's{{!}}^.* (/.+) is not signed${{!}}sbctl sign -s "\1"{{!}}e'

これはファイルパスに依存せず、「✗」文字は必要ありません。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -keyout PK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Platform Key''/" -out PK.crt
$ openssl x509 -outform DER -in PK.crt -out PK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth

"User Mode" で Platform Key を削除できるようにするために空のファイルを署名してください:

$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -keyout KEK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Key Exchange Key''/" -out KEK.crt
$ openssl x509 -outform DER -in KEK.crt -out KEK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth

Signature Database key:

$ openssl req -newkey rsa:4096 -noenc -keyout db.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Signature Database key''/" -out db.crt
$ openssl x509 -outform DER -in db.crt -out db.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/etc/efi-keys/}})、スクリプトを実行してください:

# mkdir /etc/efi-keys
# cd !$
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh
# chmod +x mkkeys.sh
# ./mkkeys.sh
''鍵に埋め込む Common Name を入力 (例: "Secure Boot")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''sbsign'' を使用してください。例えば:

# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key db.key --cert db.crt --output ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/BOOTx64.EFI

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ cert-to-efi-sig-list -g "$(< GUID.txt)" ''new_db''.crt ''new_db''.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

db 鍵を置き換えるかわりに Signature Database に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|db}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|loader.efi}} を UEFI によって自動的に起動されるデフォルトのブートローダーの場所にコピーしてください:

# cp /usr/share/preloader-signed/HashTool.efi ''esp''/EFI/BOOT/
# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/BOOT/loader.efi

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI

''shim'' は、MokList に格納されている Machine Owner Key やハッシュによってバイナリを認証することができます。

; Machine Owner Key (MOK): EFI バイナリに署名するためにユーザが生成し利用する鍵
; hash: EFI バイナリの SHA256 ハッシュ

ハッシュを用いるのは単純ですが、ブートローダやカーネルをアップデートするたびに、MokManager 内のそれらのハッシュを追加する必要があります。MOK では鍵を一度追加するだけで済みますが、ブートローダとカーネルをアップデートするたびに、それらに署名する必要があります。

====== shim でハッシュを使う ======

''shim'' は、MokList に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -nodes -keyout MOK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Machine Owner Key''/" -out MOK.crt
$ openssl x509 -outform DER -in MOK.crt -out MOK.cer

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|grubx64.efi}} という名前の) ブートローダーとカーネルに署名:

# sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

{{Expansion|shim を含めるように ISO を再パックするための手順を追加してください。}}

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI BOOTx64.EFI \
-extract /EFI/BOOT/BOOTIA32.EFI BOOTIA32.EFI \
-extract /shellx64.efi shellx64.efi \
-extract /shellia32.efi shellia32.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ sbsign --key db.key --cert db.crt --output BOOTx64.EFI BOOTx64.EFI
$ sbsign --key db.key --cert db.crt --output BOOTIA32.EFI BOOTIA32.EFI
$ sbsign --key db.key --cert db.crt --output shellx64.efi shellx64.efi
$ sbsign --key db.key --cert db.crt --output shellia32.efi shellia32.efi
$ sbsign --key db.key --cert db.crt --output vmlinuz-linux vmlinuz-linux

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI BOOTIA32.EFI ::/EFI/BOOT/
$ mcopy -D oO -i eltorito_img2_uefi.img shellx64.efi shellia32.efi ::/

変更された El Torito UEFI ブートイメージを使って ISO を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2025-10-29|850808}}

Unified Extensible Firmware Interface/セキュアブート

2025-10-29T12:47:08Z

ELC: ハンガリー語ページへのリンク

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[hu:Unified Extensible Firmware Interface (Magyar)/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ([https://gitlab.archlinux.org/archlinux/archiso/-/issues/69 archlinux/archiso#69])。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ The Meaning of all the UEFI Keys] を見てください。

セキュアブートをを使用するには最低でも '''PK''', '''KEK''', '''db''' 鍵が必要です。KEK, db, dbx 証明書は複数追加できますが、Platform Key はひとつしか使えません。

Secure Boot を "User Mode" にすると、上位の鍵を使用してアップデートに署名しないかぎり鍵を更新できなくなります (''sign-efi-sig-list'' を使用)。Platform key は自分自身で署名することができます。

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。あるいは、以下のようにすることもできます:

# sbctl verify {{!}} sed -E 's{{!}}^.* (/.+) is not signed${{!}}sbctl sign -s "\1"{{!}}e'

これはファイルパスに依存せず、「✗」文字は必要ありません。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -keyout PK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Platform Key''/" -out PK.crt
$ openssl x509 -outform DER -in PK.crt -out PK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth

"User Mode" で Platform Key を削除できるようにするために空のファイルを署名してください:

$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -keyout KEK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Key Exchange Key''/" -out KEK.crt
$ openssl x509 -outform DER -in KEK.crt -out KEK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth

Signature Database key:

$ openssl req -newkey rsa:4096 -noenc -keyout db.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Signature Database key''/" -out db.crt
$ openssl x509 -outform DER -in db.crt -out db.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/etc/efi-keys/}})、スクリプトを実行してください:

# mkdir /etc/efi-keys
# cd !$
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh
# chmod +x mkkeys.sh
# ./mkkeys.sh
''鍵に埋め込む Common Name を入力 (例: "Secure Boot")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''sbsign'' を使用してください。例えば:

# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key db.key --cert db.crt --output ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/BOOTx64.EFI

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ cert-to-efi-sig-list -g "$(< GUID.txt)" ''new_db''.crt ''new_db''.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

db 鍵を置き換えるかわりに Signature Database に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|db}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|loader.efi}} を UEFI によって自動的に起動されるデフォルトのブートローダーの場所にコピーしてください:

# cp /usr/share/preloader-signed/HashTool.efi ''esp''/EFI/BOOT/
# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/BOOT/loader.efi

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI

''shim'' は、MokList に格納されている Machine Owner Key やハッシュによってバイナリを認証することができます。

; Machine Owner Key (MOK): EFI バイナリに署名するためにユーザが生成し利用する鍵
; hash: EFI バイナリの SHA256 ハッシュ

ハッシュを用いるのは単純ですが、ブートローダやカーネルをアップデートするたびに、MokManager 内のそれらのハッシュを追加する必要があります。MOK では鍵を一度追加するだけで済みますが、ブートローダとカーネルをアップデートするたびに、それらに署名する必要があります。

====== shim でハッシュを使う ======

''shim'' は、MokList に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -nodes -keyout MOK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Machine Owner Key''/" -out MOK.crt
$ openssl x509 -outform DER -in MOK.crt -out MOK.cer

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|grubx64.efi}} という名前の) ブートローダーとカーネルに署名:

# sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

{{Expansion|shim を含めるように ISO を再パックするための手順を追加してください。}}

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI BOOTx64.EFI \
-extract /EFI/BOOT/BOOTIA32.EFI BOOTIA32.EFI \
-extract /shellx64.efi shellx64.efi \
-extract /shellia32.efi shellia32.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ sbsign --key db.key --cert db.crt --output BOOTx64.EFI BOOTx64.EFI
$ sbsign --key db.key --cert db.crt --output BOOTIA32.EFI BOOTIA32.EFI
$ sbsign --key db.key --cert db.crt --output shellx64.efi shellx64.efi
$ sbsign --key db.key --cert db.crt --output shellia32.efi shellia32.efi
$ sbsign --key db.key --cert db.crt --output vmlinuz-linux vmlinuz-linux

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI BOOTIA32.EFI ::/EFI/BOOT/
$ mcopy -D oO -i eltorito_img2_uefi.img shellx64.efi shellia32.efi ::/

変更された El Torito UEFI ブートイメージを使って ISO を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2025-10-29|850808}}

Unified Extensible Firmware Interface/セキュアブート

2025-10-29T08:51:23Z

ELC: TranslationStatus

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ([https://gitlab.archlinux.org/archlinux/archiso/-/issues/69 archlinux/archiso#69])。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ The Meaning of all the UEFI Keys] を見てください。

セキュアブートをを使用するには最低でも '''PK''', '''KEK''', '''db''' 鍵が必要です。KEK, db, dbx 証明書は複数追加できますが、Platform Key はひとつしか使えません。

Secure Boot を "User Mode" にすると、上位の鍵を使用してアップデートに署名しないかぎり鍵を更新できなくなります (''sign-efi-sig-list'' を使用)。Platform key は自分自身で署名することができます。

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。あるいは、以下のようにすることもできます:

# sbctl verify {{!}} sed -E 's{{!}}^.* (/.+) is not signed${{!}}sbctl sign -s "\1"{{!}}e'

これはファイルパスに依存せず、「✗」文字は必要ありません。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -keyout PK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Platform Key''/" -out PK.crt
$ openssl x509 -outform DER -in PK.crt -out PK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth

"User Mode" で Platform Key を削除できるようにするために空のファイルを署名してください:

$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -keyout KEK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Key Exchange Key''/" -out KEK.crt
$ openssl x509 -outform DER -in KEK.crt -out KEK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth

Signature Database key:

$ openssl req -newkey rsa:4096 -noenc -keyout db.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Signature Database key''/" -out db.crt
$ openssl x509 -outform DER -in db.crt -out db.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/etc/efi-keys/}})、スクリプトを実行してください:

# mkdir /etc/efi-keys
# cd !$
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh
# chmod +x mkkeys.sh
# ./mkkeys.sh
''鍵に埋め込む Common Name を入力 (例: "Secure Boot")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''sbsign'' を使用してください。例えば:

# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key db.key --cert db.crt --output ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/BOOTx64.EFI

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ cert-to-efi-sig-list -g "$(< GUID.txt)" ''new_db''.crt ''new_db''.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

db 鍵を置き換えるかわりに Signature Database に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|db}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|loader.efi}} を UEFI によって自動的に起動されるデフォルトのブートローダーの場所にコピーしてください:

# cp /usr/share/preloader-signed/HashTool.efi ''esp''/EFI/BOOT/
# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/BOOT/loader.efi

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI

''shim'' は、MokList に格納されている Machine Owner Key やハッシュによってバイナリを認証することができます。

; Machine Owner Key (MOK): EFI バイナリに署名するためにユーザが生成し利用する鍵
; hash: EFI バイナリの SHA256 ハッシュ

ハッシュを用いるのは単純ですが、ブートローダやカーネルをアップデートするたびに、MokManager 内のそれらのハッシュを追加する必要があります。MOK では鍵を一度追加するだけで済みますが、ブートローダとカーネルをアップデートするたびに、それらに署名する必要があります。

====== shim でハッシュを使う ======

''shim'' は、MokList に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -nodes -keyout MOK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Machine Owner Key''/" -out MOK.crt
$ openssl x509 -outform DER -in MOK.crt -out MOK.cer

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|grubx64.efi}} という名前の) ブートローダーとカーネルに署名:

# sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

{{Expansion|shim を含めるように ISO を再パックするための手順を追加してください。}}

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI BOOTx64.EFI \
-extract /EFI/BOOT/BOOTIA32.EFI BOOTIA32.EFI \
-extract /shellx64.efi shellx64.efi \
-extract /shellia32.efi shellia32.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ sbsign --key db.key --cert db.crt --output BOOTx64.EFI BOOTx64.EFI
$ sbsign --key db.key --cert db.crt --output BOOTIA32.EFI BOOTIA32.EFI
$ sbsign --key db.key --cert db.crt --output shellx64.efi shellx64.efi
$ sbsign --key db.key --cert db.crt --output shellia32.efi shellia32.efi
$ sbsign --key db.key --cert db.crt --output vmlinuz-linux vmlinuz-linux

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI BOOTIA32.EFI ::/EFI/BOOT/
$ mcopy -D oO -i eltorito_img2_uefi.img shellx64.efi shellia32.efi ::/

変更された El Torito UEFI ブートイメージを使って ISO を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2025-10-29|850808}}

Unified Extensible Firmware Interface/セキュアブート

2025-10-29T08:43:13Z

ELC: /* ISO の再パック */ Expansion（英語ページより）

Unified Extensible Firmware Interface/セキュアブート

2025-10-29T08:38:55Z

ELC: /* 署名 */ 追加の一括署名コマンド（英語ページより）

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ([https://gitlab.archlinux.org/archlinux/archiso/-/issues/69 archlinux/archiso#69])。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ The Meaning of all the UEFI Keys] を見てください。

セキュアブートをを使用するには最低でも '''PK''', '''KEK''', '''db''' 鍵が必要です。KEK, db, dbx 証明書は複数追加できますが、Platform Key はひとつしか使えません。

Secure Boot を "User Mode" にすると、上位の鍵を使用してアップデートに署名しないかぎり鍵を更新できなくなります (''sign-efi-sig-list'' を使用)。Platform key は自分自身で署名することができます。

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。あるいは、以下のようにすることもできます:

# sbctl verify {{!}} sed -E 's{{!}}^.* (/.+) is not signed${{!}}sbctl sign -s "\1"{{!}}e'

これはファイルパスに依存せず、「✗」文字は必要ありません。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -keyout PK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Platform Key''/" -out PK.crt
$ openssl x509 -outform DER -in PK.crt -out PK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth

"User Mode" で Platform Key を削除できるようにするために空のファイルを署名してください:

$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -keyout KEK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Key Exchange Key''/" -out KEK.crt
$ openssl x509 -outform DER -in KEK.crt -out KEK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth

Signature Database key:

$ openssl req -newkey rsa:4096 -noenc -keyout db.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Signature Database key''/" -out db.crt
$ openssl x509 -outform DER -in db.crt -out db.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/etc/efi-keys/}})、スクリプトを実行してください:

# mkdir /etc/efi-keys
# cd !$
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh
# chmod +x mkkeys.sh
# ./mkkeys.sh
''鍵に埋め込む Common Name を入力 (例: "Secure Boot")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''sbsign'' を使用してください。例えば:

# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key db.key --cert db.crt --output ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/BOOTx64.EFI

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ cert-to-efi-sig-list -g "$(< GUID.txt)" ''new_db''.crt ''new_db''.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

db 鍵を置き換えるかわりに Signature Database に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|db}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|loader.efi}} を UEFI によって自動的に起動されるデフォルトのブートローダーの場所にコピーしてください:

# cp /usr/share/preloader-signed/HashTool.efi ''esp''/EFI/BOOT/
# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/BOOT/loader.efi

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI

''shim'' は、MokList に格納されている Machine Owner Key やハッシュによってバイナリを認証することができます。

; Machine Owner Key (MOK): EFI バイナリに署名するためにユーザが生成し利用する鍵
; hash: EFI バイナリの SHA256 ハッシュ

ハッシュを用いるのは単純ですが、ブートローダやカーネルをアップデートするたびに、MokManager 内のそれらのハッシュを追加する必要があります。MOK では鍵を一度追加するだけで済みますが、ブートローダとカーネルをアップデートするたびに、それらに署名する必要があります。

====== shim でハッシュを使う ======

''shim'' は、MokList に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -nodes -keyout MOK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Machine Owner Key''/" -out MOK.crt
$ openssl x509 -outform DER -in MOK.crt -out MOK.cer

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|grubx64.efi}} という名前の) ブートローダーとカーネルに署名:

# sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI BOOTx64.EFI \
-extract /EFI/BOOT/BOOTIA32.EFI BOOTIA32.EFI \
-extract /shellx64.efi shellx64.efi \
-extract /shellia32.efi shellia32.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ sbsign --key db.key --cert db.crt --output BOOTx64.EFI BOOTx64.EFI
$ sbsign --key db.key --cert db.crt --output BOOTIA32.EFI BOOTIA32.EFI
$ sbsign --key db.key --cert db.crt --output shellx64.efi shellx64.efi
$ sbsign --key db.key --cert db.crt --output shellia32.efi shellia32.efi
$ sbsign --key db.key --cert db.crt --output vmlinuz-linux vmlinuz-linux

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI BOOTIA32.EFI ::/EFI/BOOT/
$ mcopy -D oO -i eltorito_img2_uefi.img shellx64.efi shellia32.efi ::/

変更された El Torito UEFI ブートイメージを使って ISO を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2024-03-28|804762}}

Unified Extensible Firmware Interface/セキュアブート

2025-10-29T08:35:20Z

ELC: /* インストールメディアを起動する */ リンク変更（英語ページより）

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ([https://gitlab.archlinux.org/archlinux/archiso/-/issues/69 archlinux/archiso#69])。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ The Meaning of all the UEFI Keys] を見てください。

セキュアブートをを使用するには最低でも '''PK''', '''KEK''', '''db''' 鍵が必要です。KEK, db, dbx 証明書は複数追加できますが、Platform Key はひとつしか使えません。

Secure Boot を "User Mode" にすると、上位の鍵を使用してアップデートに署名しないかぎり鍵を更新できなくなります (''sign-efi-sig-list'' を使用)。Platform key は自分自身で署名することができます。

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -keyout PK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Platform Key''/" -out PK.crt
$ openssl x509 -outform DER -in PK.crt -out PK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth

"User Mode" で Platform Key を削除できるようにするために空のファイルを署名してください:

$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -keyout KEK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Key Exchange Key''/" -out KEK.crt
$ openssl x509 -outform DER -in KEK.crt -out KEK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth

Signature Database key:

$ openssl req -newkey rsa:4096 -noenc -keyout db.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Signature Database key''/" -out db.crt
$ openssl x509 -outform DER -in db.crt -out db.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/etc/efi-keys/}})、スクリプトを実行してください:

# mkdir /etc/efi-keys
# cd !$
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh
# chmod +x mkkeys.sh
# ./mkkeys.sh
''鍵に埋め込む Common Name を入力 (例: "Secure Boot")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''sbsign'' を使用してください。例えば:

# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key db.key --cert db.crt --output ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/BOOTx64.EFI

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ cert-to-efi-sig-list -g "$(< GUID.txt)" ''new_db''.crt ''new_db''.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

db 鍵を置き換えるかわりに Signature Database に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|db}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|loader.efi}} を UEFI によって自動的に起動されるデフォルトのブートローダーの場所にコピーしてください:

# cp /usr/share/preloader-signed/HashTool.efi ''esp''/EFI/BOOT/
# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/BOOT/loader.efi

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI

''shim'' は、MokList に格納されている Machine Owner Key やハッシュによってバイナリを認証することができます。

; Machine Owner Key (MOK): EFI バイナリに署名するためにユーザが生成し利用する鍵
; hash: EFI バイナリの SHA256 ハッシュ

ハッシュを用いるのは単純ですが、ブートローダやカーネルをアップデートするたびに、MokManager 内のそれらのハッシュを追加する必要があります。MOK では鍵を一度追加するだけで済みますが、ブートローダとカーネルをアップデートするたびに、それらに署名する必要があります。

====== shim でハッシュを使う ======

''shim'' は、MokList に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -nodes -keyout MOK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Machine Owner Key''/" -out MOK.crt
$ openssl x509 -outform DER -in MOK.crt -out MOK.cer

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|grubx64.efi}} という名前の) ブートローダーとカーネルに署名:

# sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI BOOTx64.EFI \
-extract /EFI/BOOT/BOOTIA32.EFI BOOTIA32.EFI \
-extract /shellx64.efi shellx64.efi \
-extract /shellia32.efi shellia32.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ sbsign --key db.key --cert db.crt --output BOOTx64.EFI BOOTx64.EFI
$ sbsign --key db.key --cert db.crt --output BOOTIA32.EFI BOOTIA32.EFI
$ sbsign --key db.key --cert db.crt --output shellx64.efi shellx64.efi
$ sbsign --key db.key --cert db.crt --output shellia32.efi shellia32.efi
$ sbsign --key db.key --cert db.crt --output vmlinuz-linux vmlinuz-linux

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI BOOTIA32.EFI ::/EFI/BOOT/
$ mcopy -D oO -i eltorito_img2_uefi.img shellx64.efi shellia32.efi ::/

変更された El Torito UEFI ブートイメージを使って ISO を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2024-03-28|804762}}

FFmpeg

2025-10-29T07:40:52Z

ELC: TranslationStatus

[[Category:オーディオ]]
[[Category:ビデオ]]
[[en:FFmpeg]]
[[zh-hans:FFmpeg]]
{{Related articles start}}
{{Related|Flac を Mp3 に変換#FFmpeg を使う}}
{{Related articles end}}
プロジェクトの[https://www.ffmpeg.org/ ホームページ] より:
:FFmpeg は、音声と動画を記録、変換、そしてストリーミングするための完全でクロスプラットフォームなソリューションです。先進的な音声・動画コーデックライブラリである libavcodec が含まれています。

== インストール ==

{{Note|''libav'' や ''avconv'' など FFmpeg のフォークも存在しています。FFmpeg の現在の状態やプロジェクトの違いについては [https://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html The FFmpeg/Libav situation] を読んでください。}}

{{Pkg|ffmpeg}} パッケージを[[インストール]]してください。

開発版は {{AUR|ffmpeg-git}} パッケージでインストールできます。可能な限り多くのオプション機能を有効化してビルドする {{AUR|ffmpeg-full}} も存在します。

== エンコードの例 ==

{{Note|
* パラメータを正しい順序で指定することが重要です (例: input、video、filters、audio、output)。順序を間違うと、パラメータがスキップされたり、FFmpeg が実行されなかったりする場合があります。
* FFmpeg は、使用できる CPU スレッド数を自動的に選択するはずです。しかし、パラメータ {{ic|-threads ''number''}} を使って、使用できるスレッド数を強制したほうが良い場合もあります。
}}

[https://trac.ffmpeg.org/wiki#Encoding FFmpeg のエンコード wiki] と {{man|1|ffmpeg|EXAMPLES}} を参照してください。

=== スクリーンキャプチャ ===

FFmpeg には [https://www.ffmpeg.org/ffmpeg-devices.html#x11grab x11grab] と [https://www.ffmpeg.org/ffmpeg-devices.html#alsa-1 ALSA] の仮想デバイスが含まれており、ユーザのディスプレイ全体と音声入力をキャプチャすることができます。

スクリーンショットを撮って {{ic|screen.png}} に保存するには:

$ ffmpeg -f x11grab -video_size 1920x1080 -i $DISPLAY -vframes 1 screen.png

ここで、{{ic|-video_size}} はキャプチャする領域のサイズを指定します。

ロスレスエンコードで音声なしのスクリーンキャストを撮って {{ic|screen.mkv}} に保存するには:

$ ffmpeg -f x11grab -video_size 1920x1080 -framerate 25 -i $DISPLAY -c:v ffvhuff screen.mkv

ここでは、Huffyuv コーデックが使用されます。このコーデックは高速ですが、ファイルサイズが大きくなります。

ロッシーエンコードで音声ありのスクリーンキャストを撮って {{ic|screen.mp4}} に保存するには:

$ ffmpeg -f x11grab -video_size 1920x1080 -framerate 25 -i $DISPLAY -f alsa -i default -c:v libx264 -preset ultrafast -c:a aac screen.mp4

ここでは、x264 コーデックが最も高速なオプションで使用されます。他のコーデックを使用することもできます。(ディスクのパフォーマンスが十分でなかったり、エンコードが遅かったりで) 各フレームの書き込みが遅すぎる場合、フレームがドロップされ、動画出力がカクカクになります。

動画ストリームをファイルとして保存する必要はないが、画面共有のために仮想ウェブカメラとして使う場合、[[v4l2loopback#FFmpeg を使って X11 をキャストする]] を参照してください。

[https://trac.ffmpeg.org/wiki/Capture/Desktop#Linux 公式のドキュメント]も参照してください。

=== ウェブカメラの録画 ===

FFmpeg には [https://www.ffmpeg.org/ffmpeg-devices.html#video4linux2_002c-v4l2 video4linux2] と [https://www.ffmpeg.org/ffmpeg-devices.html#alsa-1 ALSA] の入力デバイスが含まれています。これらにより、ウェブカメラと音声入力をキャプチャすることができます。

以下のコマンドは、ウェブカメラから音声無しで動画を録画し {{ic|webcam.mp4}} に保存します。ウェブカメラが {{ic|/dev/video0}} として正しく認識されていると仮定します:

$ ffmpeg -f v4l2 -video_size 640x480 -i /dev/video0 -c:v libx264 -preset ultrafast webcam.mp4

ここで、{{ic|-video_size}} は、ウェブカメラからの許可されるイメージサイズの最大値を指定します。

上記のコマンドは無音動画を出力します。音声ありでウェブカメラから動画を録画し {{ic|webcam.mp4}} に保存するには:

$ ffmpeg -f v4l2 -video_size 640x480 -i /dev/video0 -f alsa -i default -c:v libx264 -preset ultrafast -c:a aac webcam.mp4

ここでは、x264 コーデックが最も高速なオプションで使用されます。他のコーデックを使用することもできます。(ディスクのパフォーマンスが十分でなかったり、エンコードが遅かったりで) 各フレームの書き込みが遅すぎる場合、フレームがドロップされ、動画出力がカクカクになります。

[https://trac.ffmpeg.org/wiki/Capture/Webcam#Linux 公式のドキュメント]も参照してください。

=== VOB から他のコンテナに ===

[[Wikipedia:VOB|VOB]] ファイルを一つのストリームに連結して MPEG-2 にするには:

$ cat f0.VOB f1.VOB f2.VOB | ffmpeg -i - out.mp2

=== x264 ===

==== ロスレス ====

''ultrafast'' プリセットは最速のエンコードをするので素早い録画をしたいときに有用です (スクリーンキャストなど):

$ ffmpeg -i input -c:v libx264 -preset ultrafast -qp 0 -c:a copy output

''ultrafast'' プリセットの反対は ''veryslow'' で、''ultrafast'' よりもエンコードが遅いかわりに出力するファイルのサイズが小さくなります:

$ ffmpeg -i input -c:v libx264 -preset veryslow -qp 0 -c:a copy output

どちらでも出力のクオリティは同じです。

{{Tip|あなたの使っているコンピュータがリアルタイムで {{ic|-preset superfast}} を処理できる場合、{{ic|-preset ultrafast}} ではなく {{ic|-preset superfast}} を使用してください。Ultrafast は superfast よりも圧縮率が''かなり''落ちます。}}

==== Constant rate factor ====

出力する品質を指定したいときに使います。一般的に使われているのは最高の {{ic|-crf}} 値で、これでも許容範囲内の画質になります。値が低いほど画質は高くなります。0はロスレス、18は見た目がロスレス、そして23がデフォルトの値です。賢明な値は18から28の範囲になります。一番遅い {{ic|-preset}} を使うなら辛抱する必要があります。詳しくは [https://ffmpeg.org/trac/ffmpeg/wiki/x264EncodingGuide x264 Encoding Guide] を見て下さい。

$ ffmpeg -i ''video'' -c:v libx264 -tune film -preset slow -crf 22 -x264opts fast_pskip=0 -c:a libmp3lame -aq 4 ''output''.mkv

{{ic|-tune}} オプションを使うことで[https://forum.doom9.org/showthread.php?t=149394 エンコードされるメディアの中身とタイプにあった設定にすることができます]。

==== ツーパス (超高品質) ====

マルチパスの始めは動画の統計が記録されるため、音声が無効化されます:

$ ffmpeg -i ''video''.VOB -an -vcodec libx264 -pass 1 -preset veryslow \
-threads 0 -b:v 3000k -x264opts frameref=15:fast_pskip=0 -f rawvideo -y /dev/null

コンテナの形式は出力ファイルの拡張子 ({{ic|.mkv}}) から自動的に検出して変換されます:

$ ffmpeg -i ''video''.VOB -acodec aac -b:a 256k -ar 96000 -vcodec libx264 \
-pass 2 -preset veryslow -threads 0 -b:v 3000k -x264opts frameref=15:fast_pskip=0 ''video''.mkv

==== 動画の手ブレ補正 ====

vbid.stab プラグインを使ってツーパスで手ブレ補正 (ビデオ安定化) を行います。

===== ファーストパス =====

ファーストパスでは補正パラメータを記録してファイルに書き出します、または視覚分析のテスト動画を作成します。

* 補正パラメータを記録してファイルだけに書き出す: {{bc|1=$ ffmpeg -i input -vf vidstabdetect=stepsize=4:mincontrast=0:result=transforms.trf -f null -}}
* 補正パラメータをファイルに書きだして、視覚分析用のテストビデオ "output-stab" を作成: {{bc|1=$ ffmpeg -i input -vf vidstabdetect=stepsize=4:mincontrast=0:result=transforms.trf output-stab}}

===== セカンドパス =====

セカンドパスではファーストパスで作成した補正パラメータを解析して、それを使って "output-stab_final" を生成します。セカンドパスで他のフィルターを適用することもでき、変換を繰り返す必要をなくして画質を最大限保つことができます。下のコマンドでは以下のオプションを使っています:

* {{ic|unsharp}}: vid.stab の作者によって推奨されています。下の例ではデフォルトの 5:5:1.0:5:5:1.0 を使っています。
* {{ic|1=fade=t=in:st=0:d=4}}: 4秒間のフェードインをファイルの冒頭に挟みます。
* {{ic|1=fade=t=out:st=60:d=4}}: 動画の60秒目から4秒間のフェードアウトを挟みます。
* {{ic|-c:a pcm_s16le}}: XAVC-S コーデックは pcm_s16be で記録されロスレスの pcm_s16le に変換されます。

$ ffmpeg -i input -vf vidstabtransform=smoothing=30:interpol=bicubic:input=transforms.trf,unsharp,fade=t=in:st=0:d=4,fade=t=out:st=60:d=4 -c:v libx264 -tune film -preset veryslow -crf 8 -x264opts fast_pskip=0 -c:a pcm_s16le output-stab_final

=== x265 ===

以下の例は、パラメータを指定せずに libx265 を呼び出した場合のデフォルトを示します (Constant Rate Factor エンコード):

ffmpeg -i input -c:v libx265 -crf 28 -preset medium -c:a libvorbis output.mp4

詳細は FFmpeg の [https://trac.ffmpeg.org/wiki/Encode/H.265 H.265/HEVC Video Encoding Guide] を参照してください。

=== シングルパス MPEG-2 (ニアロスレス) ===

DVD 標準のパラメータに FFmpeg を自動的に設定することができます。約 30 FPS の DVD [[Wikipedia:ja:MPEG-2|MPEG-2]] にエンコードするには:

$ ffmpeg -i ''video''.VOB -target ntsc-dvd ''output''.mpg

約 24 FPS の DVD MPEG-2 にエンコードするには:

$ ffmpeg -i ''video''.VOB -target film-dvd ''output''.mpg

=== 字幕 ===

==== 抽出 ====

MPEG-2 や Matroska などのコンテナファイルに埋め込まれた字幕を抽出して、SRT や SSA、WebVTT などの字幕形式に変換することができます。[https://trac.ffmpeg.org/wiki/ExtractSubtitles]

* ファイルに字幕ストリームが含まれているか確認してください:

{{hc|$ ffprobe -hide_banner foo.mkv|
...
Stream #0:0(und): Video: h264 (High), yuv420p, 1920x800 [SAR 1:1 DAR 12:5], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
Metadata:
CREATION_TIME : 2012-06-05 05:04:15
LANGUAGE : und
Stream #0:1(und): Audio: aac, 44100 Hz, stereo, fltp (default)
Metadata:
CREATION_TIME : 2012-06-05 05:10:34
LANGUAGE : und
HANDLER_NAME : GPAC ISO Audio Handler
'''Stream #0:2: Subtitle: ssa (default)'''
}}

* {{ic|foo.mkv}} には SSA の字幕が埋め込まれており、別のファイルに抽出することが可能です:

$ ffmpeg -i foo.mkv foo.ssa

字幕を望ましい形式 (例として [[Wikipedia:ja:SubRip|SubRip]]) に保存するには {{ic|-c:s srt}} を追加してください:

$ ffmpeg -i foo.mkv -c:s srt foo.srt

複数の字幕が存在する場合、{{ic|-map ''key'':''stream''}} パラメータを使用して抽出するストリームを指定する必要があります:

$ ffmpeg -i foo.mkv -map 0:2 foo.ssa

==== ハードサブ ====

(FFmpeg wiki の記事の [https://trac.ffmpeg.org/wiki/HowToBurnSubtitlesIntoVideo HowToBurnSubtitlesIntoVideo] に基づく説明)

[[Wikipedia:Hardsub|ハードサブ]]は動画に字幕を焼きこむことになります。ハードサブは無効化できず、言語の切り替えやフォントサイズのカスタマイズもできないため、推奨されない場合もあります。不明な場合は、ハードサブではなくソフトサブを使用してください。

* {{ic|foo.mpg}} に {{ic|foo.ssa}} の字幕を重ねるには:

$ ffmpeg -i foo.mpg -vf subtitles=foo.ssa out.mpg

=== ボリュームゲイン ===

ボリュームゲインは ''ffmpeg'' のフィルタ機能で変更できます。まず、{{ic|-af}} または {{ic|-filter:a}} を使って音声ストリームを選択し、次に、''volume'' フィルタの後にそのストリームに対するゲインを指定してください。例えば:

$ ffmpeg -i input.flac -af '''volume=1.5''' ouput.flac

ここで、{{ic|1=volume=1.5}} によって 150% のボリュームゲインとなります。1.5 から 0.5 にすると、ボリュームが半分になります。ボリュームフィルタにはデシベル単位を渡すこともできます。{{ic|1=volume=3dB}} とすると、ボリュームが 3dB 増え、{{ic|1=volume=-3dB}} とすると 3dB 減ります。

{{Note|ファイルのボリュームゲインを倍にすることは、ボリュームを倍にすることと同じではありません。実験して正しいボリュームを見つける必要があります。}}

{{Tip|''volumedetect'' フィルタを使用することで、ファイルの現在の平均ボリュームとピークボリュームを調べることができます: {{ic|ffmpeg -i input.flac -af volumedetect -f null -}}。そして、目標のレベルと現在のレベルとの差を ''volume'' フィルタに渡すことで、望みのレベルにすることができます。}}

=== ボリュームノーマライゼーション ===

''loudnorm'' フィルタによるノーマライゼーションにより、平均ボリュームとピークボリュームを特定の値にすることができます。''fmpeg'' のデフォルトの平均ラウドネス、ピークラウドネス、そしてレンジラウドネスの目標値 (それぞれ、-24 LUFS、-2 dBTP、7 LU) を使って、ファイルの知覚ラウドネスを正規化するには、以下のコマンドを使用してください:

$ ffmpeg -i input.flac -af '''loudnorm''' output.flac

別のラウドネスプロファイルを得るには、''loudnorm'' フィルタのパラメータ {{ic|i}}、{{ic|tp}}、そして {{ic|lra}} を使って、それぞれ ''i''ntegrated、''t''rue ''p''eak、''l''oudness ''ra''nge を指定してください。例えば、デフォルトよりも高い知覚ラウドネスにするには:

$ ffmpeg -i input.flac -af loudnorm=i=-16:tp=-1.5:lra=11:print_format=summary output.flac

この例では、オーディオファイルの入力ラウドネスと出力ラウドネスを表示するために {{ic|1=print_format=summary}} も追加しています。

{{Note|このフィルタはツーパスモードもサポートしています。最初の実行から測定されたラウドネス値を抽出し、その値を使って2回めの実行で線形ノーマライゼーションを行います。詳細は [https://ffmpeg.org/ffmpeg-filters.html#loudnorm ffmpeg loudnorm ドキュメント]を参照してください。}}

{{Tip|ファイルの現在のラウドネスを調べるには、{{ic|1=ffmpeg -i input.flac -af loudnorm=print_format=summary -f null -}} を使ってください。}}

=== 音声を抽出する ===

{{hc|$ ffmpeg -i ''video''.mpg output.ext|
...
Input #0, avi, from '''video''.mpg':
Duration: 01:58:28.96, start: 0.000000, bitrate: 3000 kb/s
Stream #0.0: Video: mpeg4, yuv420p, 720x480 [PAR 1:1 DAR 16:9], 29.97 tbr, 29.97 tbn, 29.97 tbc
Stream #0.1: Audio: ac3, 48000 Hz, stereo, s16, 384 kb/s
Stream #0.2: Audio: ac3, 48000 Hz, 5.1, s16, 448 kb/s
Stream #0.3: Audio: dts, 48000 Hz, 5.1 768 kb/s
...
}}

多重化されている一番目の ({{ic|-map 0:1}}) [[Wikipedia:ja:ドルビーデジタル|AC-3]] でエンコードされた音声ストリームをファイルに抽出する:

$ ffmpeg -i ''video''.mpg -map 0:1 -acodec copy -vn ''video''.ac3

三番目の ({{ic|-map 0:3}}) [[Wikipedia:ja:デジタル・シアター・システムズ|DTS]] 音声ストリームをビットレートが 192 kb/s で[[Wikipedia:ja:サンプリングレート|サンプリングレート]]が 96000 Hz の [[Wikipedia:ja:AAC|AAC]] ファイルに変換する:

$ ffmpeg -i ''video''.mpg -map 0:3 -acodec aac -b:a 192k -ar 96000 -vn ''output''.aac

{{ic|-vn}} は動画ストリームの処理を無効にします。

時間を指定して音声ストリームを抽出する:

$ ffmpeg -ss 00:01:25 -t 00:00:05 -i ''video''.mpg -map 0:1 -acodec copy -vn ''output''.ac3

{{ic|-ss}} で開始時間を、{{ic|-t}} で長さを指定します。

=== 音声を除去する ===

# 一番目の動画ストリーム ({{ic|-map 0:0}}) と二番目の AC-3 音声ストリーム ({{ic|-map 0:2}}) をコピーします。
# AC-3 音声ストリームをビットレートが 128 kb/s でサンプリングレートが 48000 Hz の2チャンネルの MP3 に変換します。

$ ffmpeg -i ''video''.mpg -map 0:0 -map 0:2 -vcodec copy -acodec libmp3lame \
-b:a 128k -ar 48000 -ac 2 ''video''.mkv

{{hc|$ ffmpeg -i ''video''.mkv|
...
Input #0, avi, from '''video''.mpg':
Duration: 01:58:28.96, start: 0.000000, bitrate: 3000 kb/s
Stream #0.0: Video: mpeg4, yuv420p, 720x480 [PAR 1:1 DAR 16:9], 29.97 tbr, 29.97 tbn, 29.97 tbc
Stream #0.1: Audio: mp3, 48000 Hz, stereo, s16, 128 kb/s
}}

{{Note|無駄な音声ストリームを削除することで余ったビットを画質の向上に割り当てることができます。}}

=== ファイルを分割する ===

{{ic|copy}} コーデックを使うことでエンコーディングを変更せずにファイルの操作を行うことができます。例えば、次のコマンドであらゆるメディアファイルを簡単に2つに分けることが可能です:

$ ffmpeg -i file.ext -t 00:05:30 -c copy part1.ext -ss 00:05:30 -c copy part2.ext

=== ハードウェアビデオアクセラレーション ===

[https://trac.ffmpeg.org/wiki/HWAccelIntro ハードウェアアクセラレーション API] を使用することで、エンコード/デコードのパフォーマンスを向上させることができます。しかし、特定の種類のコーデックしか使えませんし、場合によっては、ソフトウェアエンコードを使ったときと同じ結果が得られるとは限りません。

==== VA-API ====

Intel CPU ({{Pkg|intel-media-driver}} か {{Pkg|libva-intel-driver}} が必要) を使っている場合や、特定の AMD GPU でオープンソースの [[AMDGPU]] ドライバー ({{Pkg|mesa}} が必要) を使っている場合、[[VA-API]] を使用してエンコードとデコードができます。

利用可能なパラメータとサポートされているプラットフォームに関する情報は、[https://trac.ffmpeg.org/wiki/Hardware/VAAPI FFmpeg のドキュメント] を参照してください。

サポートされている H.264 コーデックを使用してエンコードする例:

$ ffmpeg -threads 1 -i file.ext -vaapi_device /dev/dri/renderD128 -vcodec h264_vaapi -vf format='nv12|vaapi,hwupload' output.mp4

{{Note|通常、VA-API は、(FFmpeg パッケージの依存関係である) {{Pkg|libva}} に含まれるヘッダとライブラリが検出されれば、ビルド時に {{Pkg|ffmpeg}} の自動検出機能によって有効化されます。}}

クイックリファレンスとして、constant quality エンコードを行う例を以下に挙げます:

$ ffmpeg -vaapi_device /dev/dri/renderD128 -i input.mp4 -vf 'format=nv12,hwupload' -c:v hevc_vaapi -f mp4 -rc_mode 1 -qp 25 output.mp4

hevc_vaapi を使用する場合、-qp を 25 (視覚的に等価) からそれ以上 (28 から非常に小さな視覚的な損失が発生し始めます) の間で調整してください。h264_vaapi を使用する場合、18 (視覚的に等価) からそれ以上 (20 から非常に小さな視覚的な損失が発生し始めます) の間で調整してください。また、hevc_vaapi は h264_vaapi よりも 50% 高速にエンコードできるようです。

==== NVIDIA NVENC/NVDEC ====

プロプライエタリな [[NVIDIA]] ドライバを使用していて、{{Pkg|nvidia-utils}} パッケージがインストールされている場合、[[Wikipedia:Nvidia NVENC|NVENC]] と [[Wikipedia:Nvidia NVDEC|NVDEC]] をエンコード/デコードに使用できます。サポートされている GPU は [[Wikipedia:GeForce 600 series|600 シリーズ]]からです。詳細は [[ハードウェアビデオアクセラレーション#NVIDIA]] を参照してください。

テクニックが[https://web.archive.org/web/20190808223352/https://gist.github.com/Brainiarc7/8b471ff91319483cdb725f615908286e こちらの古い gist] に載っています。NVENC は [[CUDA]] と似ているため、ターミナルセッションからでも動作します。ハードウェア NVENC は Intel の VA-API エンコーダよりも数倍高速です。

利用可能なオプションを表示するには以下のコマンドを実行してください ({{ic|hevc_nvenc}} も使えます):

$ ffmpeg -help encoder=h264_nvenc

使用例:

$ ffmpeg -i source.ext -c:v h264_nvenc -rc constqp -qp 28 output.mkv

==== Intel QuickSync (QSV) ====

{{Merge|ハードウェアビデオアクセラレーション#Intel Video Processing Library (Intel VPL)|This is not specific to ffmpeg}}

[https://www.intel.com/content/www/us/en/architecture-and-technology/quick-sync-video/quick-sync-video-general.html Intel® Quick Sync Video] は、[[Intel]] GPU のメディア処理機能を使用して高速なデコードとエンコードを行い、プロセッサが他のタスクを処理できるようにしてシステムの応答性を向上させます。

これを使用するには、'''libmfx''' ランタイム実装がインストールされている必要があります。'''libmfx''' は、ハードウェアプラットフォームに基づいて実行時に実装をロードするディスパッチャライブラリです。
[[Wikipedia:ja:Broadwellマイクロアーキテクチャ|Broadwell]] から [[Wikipedia:ja:Rocket Lakeマイクロプロセッサ|Rocket Lake]] までの GPU で実行する場合、このライブラリは {{Pkg|intel-media-sdk}} をランタイム実装としてロードします。
[[Wikipedia:ja:Tiger Lakeマイクロアーキテクチャ|Tiger Lake]] 及びそれ以降の GPU においては、'''libmfx''' は {{Pkg|vpl-gpu-rt}} をロードします。[https://github.com/intel/vpl-gpu-rt#system-requirements vpl-gpu-rt system-requirements]も参照してください。
単一の Intel GPU を搭載しているシステムでは、ランタイム実装を変更したり選択したりできません。対応する実装は、ハードウェアに応じてインストールする必要があります。

上記のランタイムをインストールしないと、以下のようなエラーが発生します:

[AVHWDeviceContext @ 0x558283838c80] Error initializing an MFX session: -3.
Device creation failed: -1313558101.

QuickSync の使用方法は [https://trac.ffmpeg.org/wiki/Hardware/QuickSync FFmpeg Wiki] で説明されています。''libmfx'' を直接使わずに ''iHD'' ドライバか ''i965'' ドライバで [[VA-API]] [https://trac.ffmpeg.org/wiki/Hardware/VAAPI] を使用することが推奨されます。エンコード例は FFmpeg Wiki の ''Hybrid transcode'' セクションを、ドライバに関する指示は [[ハードウェアビデオアクセラレーション#VA-API の設定]] を参照してください。

==== AMD AMF ====

AMD は、[[AMDGPU PRO]] プロプライエタリパッケージを使用して AMD Video Coding Engine (GPU エンコード) によって Linux で H264 のみのビデオエンコードを行うためのサポートを追加し、ffmpeg は AMF ビデオエンコードのサポートを追加しました。なので、h264_amf ビデオエンコーダを使ってエンコードするには、{{AUR|amf-amdgpu-pro}} が必要です。[[AMDGPU PRO]] パッケージによって提供されている ICD ファイルを環境変数でリンクする必要がある場合があります。そうしないと、ffmpeg はオープンな AMDGPU の ICD ファイルを使用してしまい、このビデオエンコーダを使用できません。エンコードを行うコマンドの例は以下のようになります:

$ VK_DRIVER_FILES=/usr/share/vulkan/icd.d/amd_pro_icd64.json ffmpeg -hwaccel auto -vaapi_device /dev/dri/renderD128 -i input.mkv -c:v h264_amf -rc 1 -b:v 8M h264_amf_8M.mp4

クイックリファレンスとして、constant quality エンコードを行う例を挙げましょう:

$ VK_DRIVER_FILES=/usr/share/vulkan/icd.d/amd_pro_icd64.json ffmpeg -hwaccel auto -vaapi_device /dev/dri/renderD128 -i input.mp4 -c:v h264_amf -f mp4 -rc 0 -qp_b 22 -qp_i 22 -qp_p 22 -quality 2 output.mp4

3つの -qp_(b|i|p) を調整してください。18 にすると視覚的に等価で、22 から非常に小さな視覚的な損失が発生し始めます。

=== アニメーション GIF ===

一般に、アニメーション GIF は、画像品質が悪く、ファイルサイズが比較的大きく、音声サポートもないので、動画フォーマットとして素晴らしい選択肢とは言えません。しかし、ウェブでは依然として頻繁に使用されています。以下のコマンドを使うことで、動画をアニメーション GIF に変換することができます:

$ ffmpeg -i input.mp4 -vf "fps=10,split[s0][s1];[s0]palettegen[p];[s1][p]paletteuse" -loop -1 output.gif

パレットフィルタを使って高品質な GIF を生成する方法については、https://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html を見てください。

== プリセットファイル ==

デフォルトの[https://ffmpeg.org/ffmpeg.html#Preset-files プリセットファイル]で {{ic|~/.ffmpeg}} を作成する:

$ cp -iR /usr/share/ffmpeg ~/.ffmpeg

新しいファイルを作成したりデフォルトのプリセットファイルを編集する:

{{hc|~/.ffmpeg/libavcodec-vhq.ffpreset|2=
vtag=DX50
mbd=2
trellis=2
flags=+cbp+mv0
pre_dia_size=4
dia_size=4
precmp=4
cmp=4
subcmp=4
preme=2
qns=2
}}

=== プリセットファイルを使う ===

{{ic|-vcodec}} の宣言の後に {{ic|-vpre}} オプションを加えて下さい。

==== libavcodec-vhq.ffpreset ====

* {{ic|libavcodec}} '''=''' vcodec/acodec の名前
* {{ic|vhq}} '''=''' 使用するプリセットの名前
* {{ic|ffpreset}} '''=''' FFmpeg プリセットの拡張子

== ヒントとテクニック ==

=== 出力を簡略化 ===

以下のオプションを組み合わせて使うことで、出力の詳細さを好きなレベルまで減らすことができます:

* {{ic|-hide_banner}}: 著作権表示、ビルドオプション、そしてライブラリのバージョンが表示されなくなります
* {{ic|-loglevel}}: ログレベルを調整します (微調整オプションが利用できます)。例: {{ic|-loglevel warning}}
* {{ic|-nostats}}: エンコードの進捗/統計が表示されなくなります

=== 動画の再生時間を出力 ===

$ ffprobe -select_streams v:0 -show_entries stream=duration -of default=noprint_wrappers=1:nokey=1 file.ext

=== ストリーム情報を JSON で出力 ===

$ ffprobe -v quiet -print_format json -show_format -show_streams file.ext

=== X フレームごとに動画のスクリーンショットを作成する ===

$ ffmpeg -i file.ext -an -s 319x180 -vf fps=1/'''100''' -qscale:v 75 %03d.jpg

=== メタデータの変更 ===

メタデータは直接変更することはできません。メタデータをエクスポートして変更し、新しいファイルにマージする必要があります。

既存の（グローバル）メタデータをテキストファイルに抽出する:

$ ffmpeg -i 'song.mp3' -f ffmetadata song_metadata.txt

テキストファイルからメタデータを含む新しいファイルを作成する:

$ ffmpeg -i 'song.mp3' -f ffmetadata -i new_metadata.txt -map_metadata 1 -id3v2_version 4 song_new.mp3

{{ic|-map_metadata 1}} は、ffmpeg に 2 番目のファイル (インデックスは 0 から始まる) のメタデータを使用するように指示します。

グローバルメタデータの他に、各ストリームは独自のメタデータを持つこともできます。たとえば、{{ic|-map_metadata:s:v 0:s:v}} および {{ic|-map_metadata:s:a 0:s:a}} を使用してエクスポートします。

{{ic|ffprobe}} は({{Pkg|ffmpeg}} パッケージからも同様に) 、default、compact/csv、flat、ini、json、xml など、さらに多くのエクスポート形式を提供します。

== 参照 ==

* [https://ffmpeg.org/ffmpeg.html FFmpeg documentation] - 公式ドキュメント
* [https://trac.ffmpeg.org/wiki FFmpeg Wiki] - 公式 wiki
* [http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html Encoding with the x264 codec] - MEncoder ドキュメント
* [https://avidemux.org/admWiki/doku.php?id=tutorial:h.264 H.264 encoding guide] - Avidemux wiki
* [http://howto-pages.org/ffmpeg/ Using FFmpeg] - Linux how to pages
* サポートしている音声・動画ストリームの[https://ffmpeg.org/general.html#Supported-File-Formats_002c-Codecs-or-Features リスト]

{{TranslationStatus|FFmpeg|2025-10-29|848305}}

FFmpeg

2025-10-29T07:38:09Z

ELC: /* Intel QuickSync (QSV) */ 英語ページのアナウンス

FFmpeg

2025-10-29T07:33:15Z

ELC: /* ハードウェアビデオアクセラレーション */ リンク切れ削除

[[Category:オーディオ]]
[[Category:ビデオ]]
[[en:FFmpeg]]
[[zh-hans:FFmpeg]]
{{Related articles start}}
{{Related|Flac を Mp3 に変換#FFmpeg を使う}}
{{Related articles end}}
プロジェクトの[https://www.ffmpeg.org/ ホームページ] より:
:FFmpeg は、音声と動画を記録、変換、そしてストリーミングするための完全でクロスプラットフォームなソリューションです。先進的な音声・動画コーデックライブラリである libavcodec が含まれています。

== インストール ==

{{Note|''libav'' や ''avconv'' など FFmpeg のフォークも存在しています。FFmpeg の現在の状態やプロジェクトの違いについては [https://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html The FFmpeg/Libav situation] を読んでください。}}

{{Pkg|ffmpeg}} パッケージを[[インストール]]してください。

開発版は {{AUR|ffmpeg-git}} パッケージでインストールできます。可能な限り多くのオプション機能を有効化してビルドする {{AUR|ffmpeg-full}} も存在します。

== エンコードの例 ==

{{Note|
* パラメータを正しい順序で指定することが重要です (例: input、video、filters、audio、output)。順序を間違うと、パラメータがスキップされたり、FFmpeg が実行されなかったりする場合があります。
* FFmpeg は、使用できる CPU スレッド数を自動的に選択するはずです。しかし、パラメータ {{ic|-threads ''number''}} を使って、使用できるスレッド数を強制したほうが良い場合もあります。
}}

[https://trac.ffmpeg.org/wiki#Encoding FFmpeg のエンコード wiki] と {{man|1|ffmpeg|EXAMPLES}} を参照してください。

=== スクリーンキャプチャ ===

FFmpeg には [https://www.ffmpeg.org/ffmpeg-devices.html#x11grab x11grab] と [https://www.ffmpeg.org/ffmpeg-devices.html#alsa-1 ALSA] の仮想デバイスが含まれており、ユーザのディスプレイ全体と音声入力をキャプチャすることができます。

スクリーンショットを撮って {{ic|screen.png}} に保存するには:

$ ffmpeg -f x11grab -video_size 1920x1080 -i $DISPLAY -vframes 1 screen.png

ここで、{{ic|-video_size}} はキャプチャする領域のサイズを指定します。

ロスレスエンコードで音声なしのスクリーンキャストを撮って {{ic|screen.mkv}} に保存するには:

$ ffmpeg -f x11grab -video_size 1920x1080 -framerate 25 -i $DISPLAY -c:v ffvhuff screen.mkv

ここでは、Huffyuv コーデックが使用されます。このコーデックは高速ですが、ファイルサイズが大きくなります。

ロッシーエンコードで音声ありのスクリーンキャストを撮って {{ic|screen.mp4}} に保存するには:

$ ffmpeg -f x11grab -video_size 1920x1080 -framerate 25 -i $DISPLAY -f alsa -i default -c:v libx264 -preset ultrafast -c:a aac screen.mp4

ここでは、x264 コーデックが最も高速なオプションで使用されます。他のコーデックを使用することもできます。(ディスクのパフォーマンスが十分でなかったり、エンコードが遅かったりで) 各フレームの書き込みが遅すぎる場合、フレームがドロップされ、動画出力がカクカクになります。

動画ストリームをファイルとして保存する必要はないが、画面共有のために仮想ウェブカメラとして使う場合、[[v4l2loopback#FFmpeg を使って X11 をキャストする]] を参照してください。

[https://trac.ffmpeg.org/wiki/Capture/Desktop#Linux 公式のドキュメント]も参照してください。

=== ウェブカメラの録画 ===

FFmpeg には [https://www.ffmpeg.org/ffmpeg-devices.html#video4linux2_002c-v4l2 video4linux2] と [https://www.ffmpeg.org/ffmpeg-devices.html#alsa-1 ALSA] の入力デバイスが含まれています。これらにより、ウェブカメラと音声入力をキャプチャすることができます。

以下のコマンドは、ウェブカメラから音声無しで動画を録画し {{ic|webcam.mp4}} に保存します。ウェブカメラが {{ic|/dev/video0}} として正しく認識されていると仮定します:

$ ffmpeg -f v4l2 -video_size 640x480 -i /dev/video0 -c:v libx264 -preset ultrafast webcam.mp4

ここで、{{ic|-video_size}} は、ウェブカメラからの許可されるイメージサイズの最大値を指定します。

上記のコマンドは無音動画を出力します。音声ありでウェブカメラから動画を録画し {{ic|webcam.mp4}} に保存するには:

$ ffmpeg -f v4l2 -video_size 640x480 -i /dev/video0 -f alsa -i default -c:v libx264 -preset ultrafast -c:a aac webcam.mp4

ここでは、x264 コーデックが最も高速なオプションで使用されます。他のコーデックを使用することもできます。(ディスクのパフォーマンスが十分でなかったり、エンコードが遅かったりで) 各フレームの書き込みが遅すぎる場合、フレームがドロップされ、動画出力がカクカクになります。

[https://trac.ffmpeg.org/wiki/Capture/Webcam#Linux 公式のドキュメント]も参照してください。

=== VOB から他のコンテナに ===

[[Wikipedia:VOB|VOB]] ファイルを一つのストリームに連結して MPEG-2 にするには:

$ cat f0.VOB f1.VOB f2.VOB | ffmpeg -i - out.mp2

=== x264 ===

==== ロスレス ====

''ultrafast'' プリセットは最速のエンコードをするので素早い録画をしたいときに有用です (スクリーンキャストなど):

$ ffmpeg -i input -c:v libx264 -preset ultrafast -qp 0 -c:a copy output

''ultrafast'' プリセットの反対は ''veryslow'' で、''ultrafast'' よりもエンコードが遅いかわりに出力するファイルのサイズが小さくなります:

$ ffmpeg -i input -c:v libx264 -preset veryslow -qp 0 -c:a copy output

どちらでも出力のクオリティは同じです。

{{Tip|あなたの使っているコンピュータがリアルタイムで {{ic|-preset superfast}} を処理できる場合、{{ic|-preset ultrafast}} ではなく {{ic|-preset superfast}} を使用してください。Ultrafast は superfast よりも圧縮率が''かなり''落ちます。}}

==== Constant rate factor ====

出力する品質を指定したいときに使います。一般的に使われているのは最高の {{ic|-crf}} 値で、これでも許容範囲内の画質になります。値が低いほど画質は高くなります。0はロスレス、18は見た目がロスレス、そして23がデフォルトの値です。賢明な値は18から28の範囲になります。一番遅い {{ic|-preset}} を使うなら辛抱する必要があります。詳しくは [https://ffmpeg.org/trac/ffmpeg/wiki/x264EncodingGuide x264 Encoding Guide] を見て下さい。

$ ffmpeg -i ''video'' -c:v libx264 -tune film -preset slow -crf 22 -x264opts fast_pskip=0 -c:a libmp3lame -aq 4 ''output''.mkv

{{ic|-tune}} オプションを使うことで[https://forum.doom9.org/showthread.php?t=149394 エンコードされるメディアの中身とタイプにあった設定にすることができます]。

==== ツーパス (超高品質) ====

マルチパスの始めは動画の統計が記録されるため、音声が無効化されます:

$ ffmpeg -i ''video''.VOB -an -vcodec libx264 -pass 1 -preset veryslow \
-threads 0 -b:v 3000k -x264opts frameref=15:fast_pskip=0 -f rawvideo -y /dev/null

コンテナの形式は出力ファイルの拡張子 ({{ic|.mkv}}) から自動的に検出して変換されます:

$ ffmpeg -i ''video''.VOB -acodec aac -b:a 256k -ar 96000 -vcodec libx264 \
-pass 2 -preset veryslow -threads 0 -b:v 3000k -x264opts frameref=15:fast_pskip=0 ''video''.mkv

==== 動画の手ブレ補正 ====

vbid.stab プラグインを使ってツーパスで手ブレ補正 (ビデオ安定化) を行います。

===== ファーストパス =====

ファーストパスでは補正パラメータを記録してファイルに書き出します、または視覚分析のテスト動画を作成します。

* 補正パラメータを記録してファイルだけに書き出す: {{bc|1=$ ffmpeg -i input -vf vidstabdetect=stepsize=4:mincontrast=0:result=transforms.trf -f null -}}
* 補正パラメータをファイルに書きだして、視覚分析用のテストビデオ "output-stab" を作成: {{bc|1=$ ffmpeg -i input -vf vidstabdetect=stepsize=4:mincontrast=0:result=transforms.trf output-stab}}

===== セカンドパス =====

セカンドパスではファーストパスで作成した補正パラメータを解析して、それを使って "output-stab_final" を生成します。セカンドパスで他のフィルターを適用することもでき、変換を繰り返す必要をなくして画質を最大限保つことができます。下のコマンドでは以下のオプションを使っています:

* {{ic|unsharp}}: vid.stab の作者によって推奨されています。下の例ではデフォルトの 5:5:1.0:5:5:1.0 を使っています。
* {{ic|1=fade=t=in:st=0:d=4}}: 4秒間のフェードインをファイルの冒頭に挟みます。
* {{ic|1=fade=t=out:st=60:d=4}}: 動画の60秒目から4秒間のフェードアウトを挟みます。
* {{ic|-c:a pcm_s16le}}: XAVC-S コーデックは pcm_s16be で記録されロスレスの pcm_s16le に変換されます。

$ ffmpeg -i input -vf vidstabtransform=smoothing=30:interpol=bicubic:input=transforms.trf,unsharp,fade=t=in:st=0:d=4,fade=t=out:st=60:d=4 -c:v libx264 -tune film -preset veryslow -crf 8 -x264opts fast_pskip=0 -c:a pcm_s16le output-stab_final

=== x265 ===

以下の例は、パラメータを指定せずに libx265 を呼び出した場合のデフォルトを示します (Constant Rate Factor エンコード):

ffmpeg -i input -c:v libx265 -crf 28 -preset medium -c:a libvorbis output.mp4

詳細は FFmpeg の [https://trac.ffmpeg.org/wiki/Encode/H.265 H.265/HEVC Video Encoding Guide] を参照してください。

=== シングルパス MPEG-2 (ニアロスレス) ===

DVD 標準のパラメータに FFmpeg を自動的に設定することができます。約 30 FPS の DVD [[Wikipedia:ja:MPEG-2|MPEG-2]] にエンコードするには:

$ ffmpeg -i ''video''.VOB -target ntsc-dvd ''output''.mpg

約 24 FPS の DVD MPEG-2 にエンコードするには:

$ ffmpeg -i ''video''.VOB -target film-dvd ''output''.mpg

=== 字幕 ===

==== 抽出 ====

MPEG-2 や Matroska などのコンテナファイルに埋め込まれた字幕を抽出して、SRT や SSA、WebVTT などの字幕形式に変換することができます。[https://trac.ffmpeg.org/wiki/ExtractSubtitles]

* ファイルに字幕ストリームが含まれているか確認してください:

{{hc|$ ffprobe -hide_banner foo.mkv|
...
Stream #0:0(und): Video: h264 (High), yuv420p, 1920x800 [SAR 1:1 DAR 12:5], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
Metadata:
CREATION_TIME : 2012-06-05 05:04:15
LANGUAGE : und
Stream #0:1(und): Audio: aac, 44100 Hz, stereo, fltp (default)
Metadata:
CREATION_TIME : 2012-06-05 05:10:34
LANGUAGE : und
HANDLER_NAME : GPAC ISO Audio Handler
'''Stream #0:2: Subtitle: ssa (default)'''
}}

* {{ic|foo.mkv}} には SSA の字幕が埋め込まれており、別のファイルに抽出することが可能です:

$ ffmpeg -i foo.mkv foo.ssa

字幕を望ましい形式 (例として [[Wikipedia:ja:SubRip|SubRip]]) に保存するには {{ic|-c:s srt}} を追加してください:

$ ffmpeg -i foo.mkv -c:s srt foo.srt

複数の字幕が存在する場合、{{ic|-map ''key'':''stream''}} パラメータを使用して抽出するストリームを指定する必要があります:

$ ffmpeg -i foo.mkv -map 0:2 foo.ssa

==== ハードサブ ====

(FFmpeg wiki の記事の [https://trac.ffmpeg.org/wiki/HowToBurnSubtitlesIntoVideo HowToBurnSubtitlesIntoVideo] に基づく説明)

[[Wikipedia:Hardsub|ハードサブ]]は動画に字幕を焼きこむことになります。ハードサブは無効化できず、言語の切り替えやフォントサイズのカスタマイズもできないため、推奨されない場合もあります。不明な場合は、ハードサブではなくソフトサブを使用してください。

* {{ic|foo.mpg}} に {{ic|foo.ssa}} の字幕を重ねるには:

$ ffmpeg -i foo.mpg -vf subtitles=foo.ssa out.mpg

=== ボリュームゲイン ===

ボリュームゲインは ''ffmpeg'' のフィルタ機能で変更できます。まず、{{ic|-af}} または {{ic|-filter:a}} を使って音声ストリームを選択し、次に、''volume'' フィルタの後にそのストリームに対するゲインを指定してください。例えば:

$ ffmpeg -i input.flac -af '''volume=1.5''' ouput.flac

ここで、{{ic|1=volume=1.5}} によって 150% のボリュームゲインとなります。1.5 から 0.5 にすると、ボリュームが半分になります。ボリュームフィルタにはデシベル単位を渡すこともできます。{{ic|1=volume=3dB}} とすると、ボリュームが 3dB 増え、{{ic|1=volume=-3dB}} とすると 3dB 減ります。

{{Note|ファイルのボリュームゲインを倍にすることは、ボリュームを倍にすることと同じではありません。実験して正しいボリュームを見つける必要があります。}}

{{Tip|''volumedetect'' フィルタを使用することで、ファイルの現在の平均ボリュームとピークボリュームを調べることができます: {{ic|ffmpeg -i input.flac -af volumedetect -f null -}}。そして、目標のレベルと現在のレベルとの差を ''volume'' フィルタに渡すことで、望みのレベルにすることができます。}}

=== ボリュームノーマライゼーション ===

''loudnorm'' フィルタによるノーマライゼーションにより、平均ボリュームとピークボリュームを特定の値にすることができます。''fmpeg'' のデフォルトの平均ラウドネス、ピークラウドネス、そしてレンジラウドネスの目標値 (それぞれ、-24 LUFS、-2 dBTP、7 LU) を使って、ファイルの知覚ラウドネスを正規化するには、以下のコマンドを使用してください:

$ ffmpeg -i input.flac -af '''loudnorm''' output.flac

別のラウドネスプロファイルを得るには、''loudnorm'' フィルタのパラメータ {{ic|i}}、{{ic|tp}}、そして {{ic|lra}} を使って、それぞれ ''i''ntegrated、''t''rue ''p''eak、''l''oudness ''ra''nge を指定してください。例えば、デフォルトよりも高い知覚ラウドネスにするには:

$ ffmpeg -i input.flac -af loudnorm=i=-16:tp=-1.5:lra=11:print_format=summary output.flac

この例では、オーディオファイルの入力ラウドネスと出力ラウドネスを表示するために {{ic|1=print_format=summary}} も追加しています。

{{Note|このフィルタはツーパスモードもサポートしています。最初の実行から測定されたラウドネス値を抽出し、その値を使って2回めの実行で線形ノーマライゼーションを行います。詳細は [https://ffmpeg.org/ffmpeg-filters.html#loudnorm ffmpeg loudnorm ドキュメント]を参照してください。}}

{{Tip|ファイルの現在のラウドネスを調べるには、{{ic|1=ffmpeg -i input.flac -af loudnorm=print_format=summary -f null -}} を使ってください。}}

=== 音声を抽出する ===

{{hc|$ ffmpeg -i ''video''.mpg output.ext|
...
Input #0, avi, from '''video''.mpg':
Duration: 01:58:28.96, start: 0.000000, bitrate: 3000 kb/s
Stream #0.0: Video: mpeg4, yuv420p, 720x480 [PAR 1:1 DAR 16:9], 29.97 tbr, 29.97 tbn, 29.97 tbc
Stream #0.1: Audio: ac3, 48000 Hz, stereo, s16, 384 kb/s
Stream #0.2: Audio: ac3, 48000 Hz, 5.1, s16, 448 kb/s
Stream #0.3: Audio: dts, 48000 Hz, 5.1 768 kb/s
...
}}

多重化されている一番目の ({{ic|-map 0:1}}) [[Wikipedia:ja:ドルビーデジタル|AC-3]] でエンコードされた音声ストリームをファイルに抽出する:

$ ffmpeg -i ''video''.mpg -map 0:1 -acodec copy -vn ''video''.ac3

三番目の ({{ic|-map 0:3}}) [[Wikipedia:ja:デジタル・シアター・システムズ|DTS]] 音声ストリームをビットレートが 192 kb/s で[[Wikipedia:ja:サンプリングレート|サンプリングレート]]が 96000 Hz の [[Wikipedia:ja:AAC|AAC]] ファイルに変換する:

$ ffmpeg -i ''video''.mpg -map 0:3 -acodec aac -b:a 192k -ar 96000 -vn ''output''.aac

{{ic|-vn}} は動画ストリームの処理を無効にします。

時間を指定して音声ストリームを抽出する:

$ ffmpeg -ss 00:01:25 -t 00:00:05 -i ''video''.mpg -map 0:1 -acodec copy -vn ''output''.ac3

{{ic|-ss}} で開始時間を、{{ic|-t}} で長さを指定します。

=== 音声を除去する ===

# 一番目の動画ストリーム ({{ic|-map 0:0}}) と二番目の AC-3 音声ストリーム ({{ic|-map 0:2}}) をコピーします。
# AC-3 音声ストリームをビットレートが 128 kb/s でサンプリングレートが 48000 Hz の2チャンネルの MP3 に変換します。

$ ffmpeg -i ''video''.mpg -map 0:0 -map 0:2 -vcodec copy -acodec libmp3lame \
-b:a 128k -ar 48000 -ac 2 ''video''.mkv

{{hc|$ ffmpeg -i ''video''.mkv|
...
Input #0, avi, from '''video''.mpg':
Duration: 01:58:28.96, start: 0.000000, bitrate: 3000 kb/s
Stream #0.0: Video: mpeg4, yuv420p, 720x480 [PAR 1:1 DAR 16:9], 29.97 tbr, 29.97 tbn, 29.97 tbc
Stream #0.1: Audio: mp3, 48000 Hz, stereo, s16, 128 kb/s
}}

{{Note|無駄な音声ストリームを削除することで余ったビットを画質の向上に割り当てることができます。}}

=== ファイルを分割する ===

{{ic|copy}} コーデックを使うことでエンコーディングを変更せずにファイルの操作を行うことができます。例えば、次のコマンドであらゆるメディアファイルを簡単に2つに分けることが可能です:

$ ffmpeg -i file.ext -t 00:05:30 -c copy part1.ext -ss 00:05:30 -c copy part2.ext

=== ハードウェアビデオアクセラレーション ===

[https://trac.ffmpeg.org/wiki/HWAccelIntro ハードウェアアクセラレーション API] を使用することで、エンコード/デコードのパフォーマンスを向上させることができます。しかし、特定の種類のコーデックしか使えませんし、場合によっては、ソフトウェアエンコードを使ったときと同じ結果が得られるとは限りません。

==== VA-API ====

Intel CPU ({{Pkg|intel-media-driver}} か {{Pkg|libva-intel-driver}} が必要) を使っている場合や、特定の AMD GPU でオープンソースの [[AMDGPU]] ドライバー ({{Pkg|mesa}} が必要) を使っている場合、[[VA-API]] を使用してエンコードとデコードができます。

利用可能なパラメータとサポートされているプラットフォームに関する情報は、[https://trac.ffmpeg.org/wiki/Hardware/VAAPI FFmpeg のドキュメント] を参照してください。

サポートされている H.264 コーデックを使用してエンコードする例:

$ ffmpeg -threads 1 -i file.ext -vaapi_device /dev/dri/renderD128 -vcodec h264_vaapi -vf format='nv12|vaapi,hwupload' output.mp4

{{Note|通常、VA-API は、(FFmpeg パッケージの依存関係である) {{Pkg|libva}} に含まれるヘッダとライブラリが検出されれば、ビルド時に {{Pkg|ffmpeg}} の自動検出機能によって有効化されます。}}

クイックリファレンスとして、constant quality エンコードを行う例を以下に挙げます:

$ ffmpeg -vaapi_device /dev/dri/renderD128 -i input.mp4 -vf 'format=nv12,hwupload' -c:v hevc_vaapi -f mp4 -rc_mode 1 -qp 25 output.mp4

hevc_vaapi を使用する場合、-qp を 25 (視覚的に等価) からそれ以上 (28 から非常に小さな視覚的な損失が発生し始めます) の間で調整してください。h264_vaapi を使用する場合、18 (視覚的に等価) からそれ以上 (20 から非常に小さな視覚的な損失が発生し始めます) の間で調整してください。また、hevc_vaapi は h264_vaapi よりも 50% 高速にエンコードできるようです。

==== NVIDIA NVENC/NVDEC ====

プロプライエタリな [[NVIDIA]] ドライバを使用していて、{{Pkg|nvidia-utils}} パッケージがインストールされている場合、[[Wikipedia:Nvidia NVENC|NVENC]] と [[Wikipedia:Nvidia NVDEC|NVDEC]] をエンコード/デコードに使用できます。サポートされている GPU は [[Wikipedia:GeForce 600 series|600 シリーズ]]からです。詳細は [[ハードウェアビデオアクセラレーション#NVIDIA]] を参照してください。

テクニックが[https://web.archive.org/web/20190808223352/https://gist.github.com/Brainiarc7/8b471ff91319483cdb725f615908286e こちらの古い gist] に載っています。NVENC は [[CUDA]] と似ているため、ターミナルセッションからでも動作します。ハードウェア NVENC は Intel の VA-API エンコーダよりも数倍高速です。

利用可能なオプションを表示するには以下のコマンドを実行してください ({{ic|hevc_nvenc}} も使えます):

$ ffmpeg -help encoder=h264_nvenc

使用例:

$ ffmpeg -i source.ext -c:v h264_nvenc -rc constqp -qp 28 output.mkv

==== Intel QuickSync (QSV) ====

[https://www.intel.com/content/www/us/en/architecture-and-technology/quick-sync-video/quick-sync-video-general.html Intel® Quick Sync Video] は、[[Intel]] GPU のメディア処理機能を使用して高速なデコードとエンコードを行い、プロセッサが他のタスクを処理できるようにしてシステムの応答性を向上させます。

これを使用するには、'''libmfx''' ランタイム実装がインストールされている必要があります。'''libmfx''' は、ハードウェアプラットフォームに基づいて実行時に実装をロードするディスパッチャライブラリです。
[[Wikipedia:ja:Broadwellマイクロアーキテクチャ|Broadwell]] から [[Wikipedia:ja:Rocket Lakeマイクロプロセッサ|Rocket Lake]] までの GPU で実行する場合、このライブラリは {{Pkg|intel-media-sdk}} をランタイム実装としてロードします。
[[Wikipedia:ja:Tiger Lakeマイクロアーキテクチャ|Tiger Lake]] 及びそれ以降の GPU においては、'''libmfx''' は {{Pkg|vpl-gpu-rt}} をロードします。[https://github.com/intel/vpl-gpu-rt#system-requirements vpl-gpu-rt system-requirements]も参照してください。
単一の Intel GPU を搭載しているシステムでは、ランタイム実装を変更したり選択したりできません。対応する実装は、ハードウェアに応じてインストールする必要があります。

上記のランタイムをインストールしないと、以下のようなエラーが発生します:

[AVHWDeviceContext @ 0x558283838c80] Error initializing an MFX session: -3.
Device creation failed: -1313558101.

QuickSync の使用方法は [https://trac.ffmpeg.org/wiki/Hardware/QuickSync FFmpeg Wiki] で説明されています。''libmfx'' を直接使わずに ''iHD'' ドライバか ''i965'' ドライバで [[VA-API]] [https://trac.ffmpeg.org/wiki/Hardware/VAAPI] を使用することが推奨されます。エンコード例は FFmpeg Wiki の ''Hybrid transcode'' セクションを、ドライバに関する指示は [[ハードウェアビデオアクセラレーション#VA-API の設定]] を参照してください。

==== AMD AMF ====

AMD は、[[AMDGPU PRO]] プロプライエタリパッケージを使用して AMD Video Coding Engine (GPU エンコード) によって Linux で H264 のみのビデオエンコードを行うためのサポートを追加し、ffmpeg は AMF ビデオエンコードのサポートを追加しました。なので、h264_amf ビデオエンコーダを使ってエンコードするには、{{AUR|amf-amdgpu-pro}} が必要です。[[AMDGPU PRO]] パッケージによって提供されている ICD ファイルを環境変数でリンクする必要がある場合があります。そうしないと、ffmpeg はオープンな AMDGPU の ICD ファイルを使用してしまい、このビデオエンコーダを使用できません。エンコードを行うコマンドの例は以下のようになります:

$ VK_DRIVER_FILES=/usr/share/vulkan/icd.d/amd_pro_icd64.json ffmpeg -hwaccel auto -vaapi_device /dev/dri/renderD128 -i input.mkv -c:v h264_amf -rc 1 -b:v 8M h264_amf_8M.mp4

クイックリファレンスとして、constant quality エンコードを行う例を挙げましょう:

$ VK_DRIVER_FILES=/usr/share/vulkan/icd.d/amd_pro_icd64.json ffmpeg -hwaccel auto -vaapi_device /dev/dri/renderD128 -i input.mp4 -c:v h264_amf -f mp4 -rc 0 -qp_b 22 -qp_i 22 -qp_p 22 -quality 2 output.mp4

3つの -qp_(b|i|p) を調整してください。18 にすると視覚的に等価で、22 から非常に小さな視覚的な損失が発生し始めます。

=== アニメーション GIF ===

一般に、アニメーション GIF は、画像品質が悪く、ファイルサイズが比較的大きく、音声サポートもないので、動画フォーマットとして素晴らしい選択肢とは言えません。しかし、ウェブでは依然として頻繁に使用されています。以下のコマンドを使うことで、動画をアニメーション GIF に変換することができます:

$ ffmpeg -i input.mp4 -vf "fps=10,split[s0][s1];[s0]palettegen[p];[s1][p]paletteuse" -loop -1 output.gif

パレットフィルタを使って高品質な GIF を生成する方法については、https://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html を見てください。

== プリセットファイル ==

デフォルトの[https://ffmpeg.org/ffmpeg.html#Preset-files プリセットファイル]で {{ic|~/.ffmpeg}} を作成する:

$ cp -iR /usr/share/ffmpeg ~/.ffmpeg

新しいファイルを作成したりデフォルトのプリセットファイルを編集する:

{{hc|~/.ffmpeg/libavcodec-vhq.ffpreset|2=
vtag=DX50
mbd=2
trellis=2
flags=+cbp+mv0
pre_dia_size=4
dia_size=4
precmp=4
cmp=4
subcmp=4
preme=2
qns=2
}}

=== プリセットファイルを使う ===

{{ic|-vcodec}} の宣言の後に {{ic|-vpre}} オプションを加えて下さい。

==== libavcodec-vhq.ffpreset ====

* {{ic|libavcodec}} '''=''' vcodec/acodec の名前
* {{ic|vhq}} '''=''' 使用するプリセットの名前
* {{ic|ffpreset}} '''=''' FFmpeg プリセットの拡張子

== ヒントとテクニック ==

=== 出力を簡略化 ===

以下のオプションを組み合わせて使うことで、出力の詳細さを好きなレベルまで減らすことができます:

* {{ic|-hide_banner}}: 著作権表示、ビルドオプション、そしてライブラリのバージョンが表示されなくなります
* {{ic|-loglevel}}: ログレベルを調整します (微調整オプションが利用できます)。例: {{ic|-loglevel warning}}
* {{ic|-nostats}}: エンコードの進捗/統計が表示されなくなります

=== 動画の再生時間を出力 ===

$ ffprobe -select_streams v:0 -show_entries stream=duration -of default=noprint_wrappers=1:nokey=1 file.ext

=== ストリーム情報を JSON で出力 ===

$ ffprobe -v quiet -print_format json -show_format -show_streams file.ext

=== X フレームごとに動画のスクリーンショットを作成する ===

$ ffmpeg -i file.ext -an -s 319x180 -vf fps=1/'''100''' -qscale:v 75 %03d.jpg

=== メタデータの変更 ===

メタデータは直接変更することはできません。メタデータをエクスポートして変更し、新しいファイルにマージする必要があります。

既存の（グローバル）メタデータをテキストファイルに抽出する:

$ ffmpeg -i 'song.mp3' -f ffmetadata song_metadata.txt

テキストファイルからメタデータを含む新しいファイルを作成する:

$ ffmpeg -i 'song.mp3' -f ffmetadata -i new_metadata.txt -map_metadata 1 -id3v2_version 4 song_new.mp3

{{ic|-map_metadata 1}} は、ffmpeg に 2 番目のファイル (インデックスは 0 から始まる) のメタデータを使用するように指示します。

グローバルメタデータの他に、各ストリームは独自のメタデータを持つこともできます。たとえば、{{ic|-map_metadata:s:v 0:s:v}} および {{ic|-map_metadata:s:a 0:s:a}} を使用してエクスポートします。

{{ic|ffprobe}} は({{Pkg|ffmpeg}} パッケージからも同様に) 、default、compact/csv、flat、ini、json、xml など、さらに多くのエクスポート形式を提供します。

== 参照 ==

* [https://ffmpeg.org/ffmpeg.html FFmpeg documentation] - 公式ドキュメント
* [https://trac.ffmpeg.org/wiki FFmpeg Wiki] - 公式 wiki
* [http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html Encoding with the x264 codec] - MEncoder ドキュメント
* [https://avidemux.org/admWiki/doku.php?id=tutorial:h.264 H.264 encoding guide] - Avidemux wiki
* [http://howto-pages.org/ffmpeg/ Using FFmpeg] - Linux how to pages
* サポートしている音声・動画ストリームの[https://ffmpeg.org/general.html#Supported-File-Formats_002c-Codecs-or-Features リスト]

{{TranslationStatus|FFmpeg|2023-07-23|776189}}

Unified Extensible Firmware Interface/セキュアブート

2025-10-26T12:26:55Z

ELC: /* 参照 */ 同期

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ({{Bug|53864}})。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ The Meaning of all the UEFI Keys] を見てください。

セキュアブートをを使用するには最低でも '''PK''', '''KEK''', '''db''' 鍵が必要です。KEK, db, dbx 証明書は複数追加できますが、Platform Key はひとつしか使えません。

Secure Boot を "User Mode" にすると、上位の鍵を使用してアップデートに署名しないかぎり鍵を更新できなくなります (''sign-efi-sig-list'' を使用)。Platform key は自分自身で署名することができます。

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -keyout PK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Platform Key''/" -out PK.crt
$ openssl x509 -outform DER -in PK.crt -out PK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth

"User Mode" で Platform Key を削除できるようにするために空のファイルを署名してください:

$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -keyout KEK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Key Exchange Key''/" -out KEK.crt
$ openssl x509 -outform DER -in KEK.crt -out KEK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth

Signature Database key:

$ openssl req -newkey rsa:4096 -noenc -keyout db.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Signature Database key''/" -out db.crt
$ openssl x509 -outform DER -in db.crt -out db.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/etc/efi-keys/}})、スクリプトを実行してください:

# mkdir /etc/efi-keys
# cd !$
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh
# chmod +x mkkeys.sh
# ./mkkeys.sh
''鍵に埋め込む Common Name を入力 (例: "Secure Boot")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''sbsign'' を使用してください。例えば:

# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key db.key --cert db.crt --output ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/BOOTx64.EFI

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ cert-to-efi-sig-list -g "$(< GUID.txt)" ''new_db''.crt ''new_db''.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

db 鍵を置き換えるかわりに Signature Database に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|db}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|loader.efi}} を UEFI によって自動的に起動されるデフォルトのブートローダーの場所にコピーしてください:

# cp /usr/share/preloader-signed/HashTool.efi ''esp''/EFI/BOOT/
# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/BOOT/loader.efi

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI

''shim'' は、MokList に格納されている Machine Owner Key やハッシュによってバイナリを認証することができます。

; Machine Owner Key (MOK): EFI バイナリに署名するためにユーザが生成し利用する鍵
; hash: EFI バイナリの SHA256 ハッシュ

ハッシュを用いるのは単純ですが、ブートローダやカーネルをアップデートするたびに、MokManager 内のそれらのハッシュを追加する必要があります。MOK では鍵を一度追加するだけで済みますが、ブートローダとカーネルをアップデートするたびに、それらに署名する必要があります。

====== shim でハッシュを使う ======

''shim'' は、MokList に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -nodes -keyout MOK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Machine Owner Key''/" -out MOK.crt
$ openssl x509 -outform DER -in MOK.crt -out MOK.cer

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|grubx64.efi}} という名前の) ブートローダーとカーネルに署名:

# sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI BOOTx64.EFI \
-extract /EFI/BOOT/BOOTIA32.EFI BOOTIA32.EFI \
-extract /shellx64.efi shellx64.efi \
-extract /shellia32.efi shellia32.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ sbsign --key db.key --cert db.crt --output BOOTx64.EFI BOOTx64.EFI
$ sbsign --key db.key --cert db.crt --output BOOTIA32.EFI BOOTIA32.EFI
$ sbsign --key db.key --cert db.crt --output shellx64.efi shellx64.efi
$ sbsign --key db.key --cert db.crt --output shellia32.efi shellia32.efi
$ sbsign --key db.key --cert db.crt --output vmlinuz-linux vmlinuz-linux

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI BOOTIA32.EFI ::/EFI/BOOT/
$ mcopy -D oO -i eltorito_img2_uefi.img shellx64.efi shellia32.efi ::/

変更された El Torito UEFI ブートイメージを使って ISO を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + ArchLinux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2024-03-28|804762}}

Unified Extensible Firmware Interface/セキュアブート

2025-10-26T12:25:43Z

ELC: /* オプション ROM のダイジェスト値を登録する */ 同期

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ({{Bug|53864}})。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ The Meaning of all the UEFI Keys] を見てください。

セキュアブートをを使用するには最低でも '''PK''', '''KEK''', '''db''' 鍵が必要です。KEK, db, dbx 証明書は複数追加できますが、Platform Key はひとつしか使えません。

Secure Boot を "User Mode" にすると、上位の鍵を使用してアップデートに署名しないかぎり鍵を更新できなくなります (''sign-efi-sig-list'' を使用)。Platform key は自分自身で署名することができます。

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -keyout PK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Platform Key''/" -out PK.crt
$ openssl x509 -outform DER -in PK.crt -out PK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth

"User Mode" で Platform Key を削除できるようにするために空のファイルを署名してください:

$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -keyout KEK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Key Exchange Key''/" -out KEK.crt
$ openssl x509 -outform DER -in KEK.crt -out KEK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth

Signature Database key:

$ openssl req -newkey rsa:4096 -noenc -keyout db.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Signature Database key''/" -out db.crt
$ openssl x509 -outform DER -in db.crt -out db.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/etc/efi-keys/}})、スクリプトを実行してください:

# mkdir /etc/efi-keys
# cd !$
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh
# chmod +x mkkeys.sh
# ./mkkeys.sh
''鍵に埋め込む Common Name を入力 (例: "Secure Boot")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''sbsign'' を使用してください。例えば:

# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key db.key --cert db.crt --output ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/BOOTx64.EFI

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ cert-to-efi-sig-list -g "$(< GUID.txt)" ''new_db''.crt ''new_db''.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

db 鍵を置き換えるかわりに Signature Database に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|db}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|loader.efi}} を UEFI によって自動的に起動されるデフォルトのブートローダーの場所にコピーしてください:

# cp /usr/share/preloader-signed/HashTool.efi ''esp''/EFI/BOOT/
# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/BOOT/loader.efi

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI

''shim'' は、MokList に格納されている Machine Owner Key やハッシュによってバイナリを認証することができます。

; Machine Owner Key (MOK): EFI バイナリに署名するためにユーザが生成し利用する鍵
; hash: EFI バイナリの SHA256 ハッシュ

ハッシュを用いるのは単純ですが、ブートローダやカーネルをアップデートするたびに、MokManager 内のそれらのハッシュを追加する必要があります。MOK では鍵を一度追加するだけで済みますが、ブートローダとカーネルをアップデートするたびに、それらに署名する必要があります。

====== shim でハッシュを使う ======

''shim'' は、MokList に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -nodes -keyout MOK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Machine Owner Key''/" -out MOK.crt
$ openssl x509 -outform DER -in MOK.crt -out MOK.cer

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|grubx64.efi}} という名前の) ブートローダーとカーネルに署名:

# sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI BOOTx64.EFI \
-extract /EFI/BOOT/BOOTIA32.EFI BOOTIA32.EFI \
-extract /shellx64.efi shellx64.efi \
-extract /shellia32.efi shellia32.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ sbsign --key db.key --cert db.crt --output BOOTx64.EFI BOOTx64.EFI
$ sbsign --key db.key --cert db.crt --output BOOTIA32.EFI BOOTIA32.EFI
$ sbsign --key db.key --cert db.crt --output shellx64.efi shellx64.efi
$ sbsign --key db.key --cert db.crt --output shellia32.efi shellia32.efi
$ sbsign --key db.key --cert db.crt --output vmlinuz-linux vmlinuz-linux

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI BOOTIA32.EFI ::/EFI/BOOT/
$ mcopy -D oO -i eltorito_img2_uefi.img shellx64.efi shellia32.efi ::/

変更された El Torito UEFI ブートイメージを使って ISO を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

次のようにすると、簡単に解析できるダイジェストのリストが出力されます:

# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -o 'Digest: "[a-f0-9]\{64\}"' | sed 's/Digest: "//;s/"$//'

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、{{AUR|digest-to-efi-sig-list}} を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

ダイジェストが多数ある場合、[https://gist.github.com/Strykar/5d57145962bb1bcc00ef52f380697e55 このような Bash スクリプト] を使用することもできます。

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + Arch Linux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2024-03-28|804762}}

Unified Extensible Firmware Interface/セキュアブート

2025-10-26T12:22:32Z

ELC: /* 公式の ISO で MOK と shim を使用する */ 英語ページより追加

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ({{Bug|53864}})。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ The Meaning of all the UEFI Keys] を見てください。

セキュアブートをを使用するには最低でも '''PK''', '''KEK''', '''db''' 鍵が必要です。KEK, db, dbx 証明書は複数追加できますが、Platform Key はひとつしか使えません。

Secure Boot を "User Mode" にすると、上位の鍵を使用してアップデートに署名しないかぎり鍵を更新できなくなります (''sign-efi-sig-list'' を使用)。Platform key は自分自身で署名することができます。

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -keyout PK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Platform Key''/" -out PK.crt
$ openssl x509 -outform DER -in PK.crt -out PK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth

"User Mode" で Platform Key を削除できるようにするために空のファイルを署名してください:

$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -keyout KEK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Key Exchange Key''/" -out KEK.crt
$ openssl x509 -outform DER -in KEK.crt -out KEK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth

Signature Database key:

$ openssl req -newkey rsa:4096 -noenc -keyout db.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Signature Database key''/" -out db.crt
$ openssl x509 -outform DER -in db.crt -out db.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/etc/efi-keys/}})、スクリプトを実行してください:

# mkdir /etc/efi-keys
# cd !$
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh
# chmod +x mkkeys.sh
# ./mkkeys.sh
''鍵に埋め込む Common Name を入力 (例: "Secure Boot")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''sbsign'' を使用してください。例えば:

# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key db.key --cert db.crt --output ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/BOOTx64.EFI

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ cert-to-efi-sig-list -g "$(< GUID.txt)" ''new_db''.crt ''new_db''.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

db 鍵を置き換えるかわりに Signature Database に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|db}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|loader.efi}} を UEFI によって自動的に起動されるデフォルトのブートローダーの場所にコピーしてください:

# cp /usr/share/preloader-signed/HashTool.efi ''esp''/EFI/BOOT/
# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/BOOT/loader.efi

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI

''shim'' は、MokList に格納されている Machine Owner Key やハッシュによってバイナリを認証することができます。

; Machine Owner Key (MOK): EFI バイナリに署名するためにユーザが生成し利用する鍵
; hash: EFI バイナリの SHA256 ハッシュ

ハッシュを用いるのは単純ですが、ブートローダやカーネルをアップデートするたびに、MokManager 内のそれらのハッシュを追加する必要があります。MOK では鍵を一度追加するだけで済みますが、ブートローダとカーネルをアップデートするたびに、それらに署名する必要があります。

====== shim でハッシュを使う ======

''shim'' は、MokList に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -nodes -keyout MOK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Machine Owner Key''/" -out MOK.crt
$ openssl x509 -outform DER -in MOK.crt -out MOK.cer

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|grubx64.efi}} という名前の) ブートローダーとカーネルに署名:

# sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI BOOTx64.EFI \
-extract /EFI/BOOT/BOOTIA32.EFI BOOTIA32.EFI \
-extract /shellx64.efi shellx64.efi \
-extract /shellia32.efi shellia32.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ sbsign --key db.key --cert db.crt --output BOOTx64.EFI BOOTx64.EFI
$ sbsign --key db.key --cert db.crt --output BOOTIA32.EFI BOOTIA32.EFI
$ sbsign --key db.key --cert db.crt --output shellx64.efi shellx64.efi
$ sbsign --key db.key --cert db.crt --output shellia32.efi shellia32.efi
$ sbsign --key db.key --cert db.crt --output vmlinuz-linux vmlinuz-linux

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI BOOTIA32.EFI ::/EFI/BOOT/
$ mcopy -D oO -i eltorito_img2_uefi.img shellx64.efi shellia32.efi ::/

変更された El Torito UEFI ブートイメージを使って ISO を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

==== 公式の ISO で MOK と shim を使用する ====

ブートローダー、カーネル、UEFI シェルを抽出し、署名してから、署名されたファイルと shim を使用して ISO を再パックすることで、Machine Owner Key (MOK) を備えた shim を使用したセキュアブートのサポートを公式 ISO に追加できます。

まず、関連ファイルとEl Toritoブートイメージを抽出します。shimが認識できるように、ブートローダーファイル名は {{ic|grubx64.efi}} にする必要があります。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI grubx64.efi \
-extract /shellx64.efi shellx64.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w grubx64.efi shellx64.efi vmlinuz-linux

ファイルを MOK で署名します:

$ sbsign --key MOK.key --cert MOK.crt --output grubx64.efi grubx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output shellx64.efi shellx64.efi
$ sbsign --key MOK.key --cert MOK.crt --output vmlinuz-linux vmlinuz-linux

{{AUR|shim-signed}} などをインストールして、事前署名された shim EFI バイナリを取得します。shim と MokManager を現在のディレクトリに配置し、shim EFI バイナリのファイル名を {{ic|BOOTx64.EFI}} に変更します:

$ cp /usr/share/shim-signed/shimx64.efi BOOTx64.EFI
$ cp /usr/share/shim-signed/mmx64.efi ./

shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を {{ic|eltorito_img2_uefi.img}} にコピーします。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img MOK.cer shellx64.efi ::/
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI grubx64.efi mmx64.efi ::/EFI/BOOT/

変更された El Torito UEFI ブートイメージを使用して ISO を再パックし、shim、MokManager、署名された EFI バイナリ、および DER 形式の MOK を ISO 9660 に追加します:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ / shellx64.efi MOK.cer -- \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI grubx64.efi mmx64.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

作成された {{ic|archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso}} を起動します。MokManager が起動したら、''Enroll key from disk'' > ''ARCHISO_EFI'' > ''MOK.cer'' を選択します。キーを登録した後、再起動すると、次回の起動時にライブ環境が正常に起動します。

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、''digest-to-efi-sig-list'' を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + Arch Linux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2024-03-28|804762}}

Unified Extensible Firmware Interface/セキュアブート

2025-10-26T12:12:06Z

ELC: /* ブートローダを PreLoader に置き換える */ 同期

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ({{Bug|53864}})。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ The Meaning of all the UEFI Keys] を見てください。

セキュアブートをを使用するには最低でも '''PK''', '''KEK''', '''db''' 鍵が必要です。KEK, db, dbx 証明書は複数追加できますが、Platform Key はひとつしか使えません。

Secure Boot を "User Mode" にすると、上位の鍵を使用してアップデートに署名しないかぎり鍵を更新できなくなります (''sign-efi-sig-list'' を使用)。Platform key は自分自身で署名することができます。

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -keyout PK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Platform Key''/" -out PK.crt
$ openssl x509 -outform DER -in PK.crt -out PK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth

"User Mode" で Platform Key を削除できるようにするために空のファイルを署名してください:

$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -keyout KEK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Key Exchange Key''/" -out KEK.crt
$ openssl x509 -outform DER -in KEK.crt -out KEK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth

Signature Database key:

$ openssl req -newkey rsa:4096 -noenc -keyout db.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Signature Database key''/" -out db.crt
$ openssl x509 -outform DER -in db.crt -out db.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/etc/efi-keys/}})、スクリプトを実行してください:

# mkdir /etc/efi-keys
# cd !$
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh
# chmod +x mkkeys.sh
# ./mkkeys.sh
''鍵に埋め込む Common Name を入力 (例: "Secure Boot")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''sbsign'' を使用してください。例えば:

# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key db.key --cert db.crt --output ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/BOOTx64.EFI

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ cert-to-efi-sig-list -g "$(< GUID.txt)" ''new_db''.crt ''new_db''.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

db 鍵を置き換えるかわりに Signature Database に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|db}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|loader.efi}} を UEFI によって自動的に起動されるデフォルトのブートローダーの場所にコピーしてください:

# cp /usr/share/preloader-signed/HashTool.efi ''esp''/EFI/BOOT/
# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/BOOT/loader.efi

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI

''shim'' は、MokList に格納されている Machine Owner Key やハッシュによってバイナリを認証することができます。

; Machine Owner Key (MOK): EFI バイナリに署名するためにユーザが生成し利用する鍵
; hash: EFI バイナリの SHA256 ハッシュ

ハッシュを用いるのは単純ですが、ブートローダやカーネルをアップデートするたびに、MokManager 内のそれらのハッシュを追加する必要があります。MOK では鍵を一度追加するだけで済みますが、ブートローダとカーネルをアップデートするたびに、それらに署名する必要があります。

====== shim でハッシュを使う ======

''shim'' は、MokList に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -nodes -keyout MOK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Machine Owner Key''/" -out MOK.crt
$ openssl x509 -outform DER -in MOK.crt -out MOK.cer

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|grubx64.efi}} という名前の) ブートローダーとカーネルに署名:

# sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI BOOTx64.EFI \
-extract /EFI/BOOT/BOOTIA32.EFI BOOTIA32.EFI \
-extract /shellx64.efi shellx64.efi \
-extract /shellia32.efi shellia32.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ sbsign --key db.key --cert db.crt --output BOOTx64.EFI BOOTx64.EFI
$ sbsign --key db.key --cert db.crt --output BOOTIA32.EFI BOOTIA32.EFI
$ sbsign --key db.key --cert db.crt --output shellx64.efi shellx64.efi
$ sbsign --key db.key --cert db.crt --output shellia32.efi shellia32.efi
$ sbsign --key db.key --cert db.crt --output vmlinuz-linux vmlinuz-linux

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI BOOTIA32.EFI ::/EFI/BOOT/
$ mcopy -D oO -i eltorito_img2_uefi.img shellx64.efi shellia32.efi ::/

変更された El Torito UEFI ブートイメージを使って ISO を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI loader.efi
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、''digest-to-efi-sig-list'' を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + Arch Linux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2024-03-28|804762}}

Unified Extensible Firmware Interface/セキュアブート

2025-10-26T12:09:30Z

ELC: /* 公式の ISO をカスタムの鍵で署名する */ 同期

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ({{Bug|53864}})。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ The Meaning of all the UEFI Keys] を見てください。

セキュアブートをを使用するには最低でも '''PK''', '''KEK''', '''db''' 鍵が必要です。KEK, db, dbx 証明書は複数追加できますが、Platform Key はひとつしか使えません。

Secure Boot を "User Mode" にすると、上位の鍵を使用してアップデートに署名しないかぎり鍵を更新できなくなります (''sign-efi-sig-list'' を使用)。Platform key は自分自身で署名することができます。

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -keyout PK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Platform Key''/" -out PK.crt
$ openssl x509 -outform DER -in PK.crt -out PK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth

"User Mode" で Platform Key を削除できるようにするために空のファイルを署名してください:

$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -keyout KEK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Key Exchange Key''/" -out KEK.crt
$ openssl x509 -outform DER -in KEK.crt -out KEK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth

Signature Database key:

$ openssl req -newkey rsa:4096 -noenc -keyout db.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Signature Database key''/" -out db.crt
$ openssl x509 -outform DER -in db.crt -out db.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/etc/efi-keys/}})、スクリプトを実行してください:

# mkdir /etc/efi-keys
# cd !$
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh
# chmod +x mkkeys.sh
# ./mkkeys.sh
''鍵に埋め込む Common Name を入力 (例: "Secure Boot")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''sbsign'' を使用してください。例えば:

# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key db.key --cert db.crt --output ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/BOOTx64.EFI

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ cert-to-efi-sig-list -g "$(< GUID.txt)" ''new_db''.crt ''new_db''.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

db 鍵を置き換えるかわりに Signature Database に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|db}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|loader.efi}} を UEFI によって自動的に起動されるデフォルトのブートローダーの場所にコピーしてください:

# cp /usr/share/preloader-signed/HashTool.efi ''esp''/EFI/BOOT/
# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/BOOT/loader.efi

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI

''shim'' は、MokList に格納されている Machine Owner Key やハッシュによってバイナリを認証することができます。

; Machine Owner Key (MOK): EFI バイナリに署名するためにユーザが生成し利用する鍵
; hash: EFI バイナリの SHA256 ハッシュ

ハッシュを用いるのは単純ですが、ブートローダやカーネルをアップデートするたびに、MokManager 内のそれらのハッシュを追加する必要があります。MOK では鍵を一度追加するだけで済みますが、ブートローダとカーネルをアップデートするたびに、それらに署名する必要があります。

====== shim でハッシュを使う ======

''shim'' は、MokList に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -nodes -keyout MOK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Machine Owner Key''/" -out MOK.crt
$ openssl x509 -outform DER -in MOK.crt -out MOK.cer

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|grubx64.efi}} という名前の) ブートローダーとカーネルに署名:

# sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI BOOTx64.EFI \
-extract /EFI/BOOT/BOOTIA32.EFI BOOTIA32.EFI \
-extract /shellx64.efi shellx64.efi \
-extract /shellia32.efi shellia32.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ sbsign --key db.key --cert db.crt --output BOOTx64.EFI BOOTx64.EFI
$ sbsign --key db.key --cert db.crt --output BOOTIA32.EFI BOOTIA32.EFI
$ sbsign --key db.key --cert db.crt --output shellx64.efi shellx64.efi
$ sbsign --key db.key --cert db.crt --output shellia32.efi shellia32.efi
$ sbsign --key db.key --cert db.crt --output vmlinuz-linux vmlinuz-linux

署名された EFI バイナリを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 8 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img vmlinuz-linux ::/arch/boot/x86_64/vmlinuz-linux
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI BOOTIA32.EFI ::/EFI/BOOT/
$ mcopy -D oO -i eltorito_img2_uefi.img shellx64.efi shellia32.efi ::/

変更された El Torito UEFI ブートイメージを使って ISO を再パックし、署名された EFI バイナリを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

{{Note|ISO の GRUB EFI バイナリ ({{ic|EFI/BOOT/BOOTx64.EFI}}) は {{ic|--disable-shim-lock}} でビルドされているため、shim で使用することはできません。これは GRUB の制限であり、GRUB に shim かカスタムの署名のどちらか一方との互換性を持たせることはできますが、同時に両方との互換性を持たせることはできません。}}

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-cpx /EFI/BOOT/BOOTx64.EFI ./
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ mv BOOTx64.EFI loader.efi
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、''digest-to-efi-sig-list'' を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + Arch Linux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2024-03-28|804762}}

Unified Extensible Firmware Interface/セキュアブート

2025-10-26T12:05:26Z

ELC: /* 登録されたハッシュ/鍵を削除する */ 同期

[[Category:ブートプロセス]]
[[en:Unified Extensible Firmware Interface/Secure Boot]]
[[zh-hans:Unified Extensible Firmware Interface (简体中文)/Secure Boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|セキュリティ}}
{{Related articles end}}

[[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート|セキュアブート]]とは、[[UEFI]] 規格に含まれているセキュリティ機能であり、[[Arch ブートプロセス|プリブートプロセス]]に保護レイヤを追加するために設計されました。起動時の実行を許可/禁止されているバイナリの暗号署名されたリストを保持することにより、マシンのコアブートコンポーネント (ブートマネージャ、カーネル、initramfs) が改ざんされていないという信頼性を高めるのに役立ちます。

なので、セキュアブートは、コンピュータ環境を[[セキュリティ|セキュアに保つ]]試みの一環、あるいはそれを補完するものであるとみなせます。[[dm-crypt/システム全体の暗号化|システムの暗号化]]のような他のソフトウェアのセキュリティ対策では簡単に[[dm-crypt/システム全体の暗号化#boot パーティションの暗号化 (GRUB)|カバー]]できない攻撃対象領域を減らしますが、完全に異なったものであり、それらに依存していません。セキュアブートは、独自の長所と[[wikipedia:Unified_Extensible_Firmware_Interface#Secure_Boot_2|短所]]を備えた、現在のセキュリティ慣例の一つの要素として独立しています。

{{Note|Linux におけるセキュアブートについてのより詳細な概要は、[https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] の記事と[[#参照|他のオンライン上のリソース]] を参照してください。この記事では、Arch Linux でセキュアブートをセットアップする方法に焦点を置いています。}}

== セキュアブートの状態を確認する ==

=== OS の起動前 ===

OS の起動前にセキュアブートの状態を確認するには、ファームウェアのセットアップ画面を見る必要があります。すでにマシンが起動済みであれば、ほとんどの場合再起動する必要があります。

起動プロセス中に特別なキーを押すことでファームウェアのセットアップ画面にアクセスできます。それがどのキーかはファームウェアに依りますが、通常 {{ic|Esc}}、{{ic|F2}}、{{ic|Del}} のどれかです。もしかするとその他のファンクションキーかもしれません。ファームウェアによっては、どのキー押すべきかが起動プロセスの開始時に短い時間表示されます。通常、マザーボードのマニュアルにキーが記載されています。マシンの電源を入れたらすぐに(スクリーンが表示されるよりも前に)キーを押して、そのまま押し続ける必要があるかもしれません。

ファームウェアのセットアップ画面に入ったら、意図せずに設定を変更してしまわないよう気をつけてください。通常、セットアップ画面の下部に案内指示や設定の短いヘルプがあります。セットアップ自体はいくつかのページから構成されているかもしれません。それらのページの中から正しい場所に移動する必要があります。設定は単に「セキュアブート」と表示されるかもしれません(これでオン/オフを設定できます)。

=== OS の起動後 ===

[[systemd]] を使用するシステム上では、{{man|1|bootctl}} でセキュアブートの状態を簡単に確認できます:

{{Note|以下のコマンドを実行するために systemd-boot をブートマネージャとして使う必要はありません。これは他の *ctl systemd ユーティリティ (localectl, timedatectl...) と似たもので、設定に干渉しません。}}

{{hc|$ bootctl|
System:
Firmware: UEFI 2.80 (American Megatrends 5.26)
Firmware Arch: x64
Secure Boot: enabled (user)
TPM2 Support: yes
Measured UKI: yes
Boot into FW: supported
...
}}

ここでは、セキュアブートが (ユーザモードで) 有効化され強制されていることがわかります。他に取りうる値としては、Setup Mode の場合は {{ic|disabled (setup)}}、セキュアブートが無効化されている場合は {{ic|disabled (disabled)}}、ファームウェアにセキュアブートのサポートがない場合は {{ic|disabled (unsupported)}} があります。

マシンがセキュアブートで起動されているかどうかを調べる他の方法は、以下のコマンドを使用することです:

$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

セキュアブートが有効化されている場合、このコマンドは5桁の数値を出力し、最後の値が {{ic|1}} となります。例えば:

6 0 0 0 1

しかし、機能が不十分なブートローダを使用している場合、(ファームウェアで有効になっている場合でも) カーネルがセキュアブートを検出できない場合があります。これは、システムの起動直後にカーネルのメッセージを確認することで確認できます:

{{hc|# journalctl -kg 'secure boot'|
kernel: Secure boot disabled
kernel: Secure boot could not be determined
}}

セキュアブートが検出された場合、カーネルメッセージは {{ic|Secure boot enabled}} となります。

== インストールメディアを起動する ==

公式の Arch インストールイメージはセキュアブートをサポートしていません ({{Bug|53864}})。Arch インストールメディアのセキュアブートサポートは {{ic|archlinux-2013.07.01-dual.iso}} で初めて追加されました。しかし、その後 {{ic|archlinux-2016.06.01-dual.iso}} で削除されました。その時、''prebootloader'' は、未署名の EFI バイナリを使用する {{pkg|efitools}} に置き換えられました。それ以降、公式のインストールメディアにセキュアブートのサポートが追加されることはありませんでした。

インストールメディアをセキュアブートのシステムでブートするには、セキュアブートを無効化するか、イメージを変更して署名されたブートローダを追加する必要があります。

[https://gitlab.archlinux.org/tpowa/archboot/-/wikis/Archboot-Homepage Archboot] イメージはインストールメディアでセキュアブートを使用する手段を提供します。

=== セキュアブートを無効化する ===

セキュアブートの機能は UEFI インターフェイスを通して無効化できます。ファームウェアの設定画面にアクセスする方法は [[#OS の起動前]] で説明されています。

ホットキーが使用できず Windows が起動する場合、次の方法で強制的にファームウェア設定を開くように再起動できます (Windows 10 の場合): ''Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart''。

一部のマザーボード (例: Packard Bell 製ノートパソコンや最近の Xiaomi ノートパソコン) では、管理者パスワードを設定しないとセキュアブートを無効化できません (無効化した後に管理者パスワードは消去できます)。[https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith の Secure Boot 無効化に関する記事] も参照。

=== インストールイメージを再パックする ===

[[#ISO の再パック]] を見てください。

=== インストールメディアを編集する ===

[[USB インストールメディア]]を使用している場合、そのメディア上の [[EFI システムパーティション]]を手動で編集してセキュアブートのサポートを追加することが可能です。

USB ドライブを挿入し、EFI システムパーティションを[[マウント]]してください:

# mount /dev/disk/by-label/ARCHISO_EFI /mnt

そして、[[#署名済みのブートローダを使う]] の指示に従って、署名済みのブートローダをインストールしてください。例えば、[[#PreLoader]] をインストールするには:

{{bc|
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
}}

== セキュアブートを実現する ==

''セキュアブート''の理想的なセットアップを実現するにはいくつか条件があります:

# UEFI がほぼ信頼されていて(しかし、いくつかのよく知られた[[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|批判]]と脆弱性[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]がある)、必ず[[#セキュアブートを保護する|強力なパスワードで保護されている]]こと。
# メーカー/サードパーティーのデフォルトの鍵は、セキュアブートのセキュリティモデルを大幅に弱化させることが判明しているので、使用しないこと。[https://habr.com/ru/post/446238/]
# セキュアブートによって確立された信頼の鎖をブート中に維持して攻撃面を減らすために、マイクロコード(必要な場合)と initramfs を含む、ユーザ署名済み結合 [[EFI ブートスタブ]] カーネルイメージ(ブートマネージャ無し)を UEFI が直接ロードすること。
# マシンへ物理的にアクセスできる誰かが、カーネルイメージの作成と署名プロセスで使用されるツールとファイルにアクセスしたり改ざんしたりできないようにするために、[[dm-crypt/システム全体の暗号化|ドライブの完全暗号化]]を使用すること。
# [[TPM]] を使うことでさらに改善することができるかもしれません。

シンプルかつ完全に自立したセットアップは [[#自分の鍵を使う]] で説明されています。一方、[[#署名済みのブートローダを使う]] では、サードパーティにより署名された中間ツールを使用します。

[[GRUB]] ブートローダを使うには、セキュアブートを有効化する前に追加の手順が必要になります。詳細は [[GRUB#セキュアブートサポート]] を参照してください。

=== 自分の鍵を使う ===

{{Warning|プラットフォームの鍵をあなたの鍵で置き換えると、一部のマシン(ノート PC を含む)でハードウェアを文鎮化してしまう可能性があります。そうなると、修正するためにファームウェアの設定画面に入ることが不可能になります。これは、一部のデバイス (GPU など) の (ブート中に実行される) ファームウェア([[Wikipedia:OpROM|OpROMs]])が [[#Microsoft Windows|Microsoft 3rd Party UEFI CA 証明書]]またはベンダー証明書を使って署名されているためです。これは、UEFI アプリケーションとファームウェアの署名に Lenovo CA 証明書を使用する多くの [https://forums.lenovo.com/t5/Other-Linux-Discussions/Reports-of-custom-secure-boot-keys-bricking-recent-X-P-and-T-series-laptops/m-p/5105571 Lenovo Thinkpad X、P、および T シリーズのノート PC] に当てはまります。}}

セキュアブートでは以下の鍵が使われます:

; Platform Key (PK): トップレベル鍵
; Key Exchange Key (KEK): Signature Database や Forbidden Signatures Database の更新に署名するのに使われる鍵
; Signature Database (db): EFI バイナリに署名するのに使われる鍵やハッシュが含まれます
; Forbidden Signatures Database (dbx): EFI バイナリを拒否リストに追加するために使われる鍵やハッシュが含まれます

より詳細な説明は [https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ The Meaning of all the UEFI Keys] を見てください。

セキュアブートをを使用するには最低でも '''PK''', '''KEK''', '''db''' 鍵が必要です。KEK, db, dbx 証明書は複数追加できますが、Platform Key はひとつしか使えません。

Secure Boot を "User Mode" にすると、上位の鍵を使用してアップデートに署名しないかぎり鍵を更新できなくなります (''sign-efi-sig-list'' を使用)。Platform key は自分自身で署名することができます。

==== 現在の変数をバックアップする ====

新しい鍵を作成したり EFI 変数を変更したりする前に、現在の変数をバックアップしておくことを推奨します。そうすれば、エラーが発生した場合に変数を復元できます。

主要なセキュアブートの変数4つを全てバックアップするには、{{Pkg|efitools}} パッケージを[[インストール]]し、以下のコマンドを実行してください:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done

新しいコンピュータやマザーボードでこれらのコマンドを実行する場合、抽出される変数はおそらくマイクロソフトにより提供されたものでしょう。

==== ファームウェアを "Setup Mode" にする ====

Platform Key が削除されると、セキュアブートは Setup Mode になります。ファームウェアを Setup Mode にするには、ファームウェア設定ユーティリティに入り、証明書を削除/クリアするオプションを探してください。設定ユーティリティに入る方法は [[#OS の起動前]] で説明されています。

==== systemd でより簡単に行う ====

バージョン257以降では、[[systemd]]と[[systemd-boot]]を使ってセキュアブートを簡単に設定できます。{{Pkg|systemd-ukify}}をインストールしてください。

{{Note|この方法ではMicrosoftの証明書は含まれません。[[#オプション ROM のダイジェスト値を登録する]]および[[#他のオペレーティングシステムとデュアルブートする]]を参照してください。}}

まず、[[ユニファイドカーネルイメージ#ukify]] のように希望する構成を設定し（/usr/lib/kernel/uki.conf のテンプレートを使用できます）、次に署名キーを生成します:

# ukify genkey --config /etc/kernel/uki.conf
Using config file: /etc/kernel/uki.conf
Writing SecureBoot private key to /etc/kernel/secure-boot-private-key.pem
Writing SecureBoot certificate to /etc/kernel/secure-boot-certificate.pem

{{Tip|[[kernel-install]] は自動的にこの構成を使用して [[ユニファイドカーネルイメージ]] に署名します。}}

新しく作成したキーでブートローダーに署名します（自動化については、[[systemd-boot#セキュアブートのための署名]]を参照してください）:

# /usr/lib/systemd/systemd-sbsign sign \
--private-key /etc/kernel/secure-boot-private-key.pem \
--certificate /etc/kernel/secure-boot-certificate.pem \
--output /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed \
/usr/lib/systemd/boot/efi/systemd-bootx64.efi

次に、[[ESP]]に自動登録を設定します:

# bootctl install --secure-boot-auto-enroll yes \
--certificate /etc/kernel/secure-boot-certificate.pem \
--private-key /etc/kernel/secure-boot-private-key.pem

これにより、署名された [[systemd-boot]] ブートローダーが [[ESP]] にインストール (または更新) され、{{ic|/boot/loader/keys/auto/}} に {{ic|PK.auth}}、{{ic|KEK.auth}}、{{ic|db.auth}} の 3 つのファイルが作成されます。個別の Platform Key、Key Exchange Key は生成されませんが、代わりに署名キーが 3 つのレベルすべてに登録されます。

最後に、{{ic|/boot/loader/loader.conf}} に {{ic|secure-boot-enroll force}} を設定し、再起動してファームウェアにキーを登録します。{{man|5|loader.conf}} を参照してください。

==== sbctl でより簡単に行う ====

[https://github.com/Foxboron/sbctl sbctl] は、セキュアブートをセットアップしたりファイルを署名したりするユーザーフレンドリーな方法です。

{{Note|sbctl はすべてのハードウェアで動作するわけではありません。このツールがうまく動作するかはハードウェアの製造元に掛かっています。}}

使用するには {{Pkg|sbctl}} を[[インストール]]してください。[https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] と {{man|8|sbctl}} も参照してください。

===== キーを作成・登録する =====

始める前に、ファームウェアの設定画面に行き、セキュアブートのモードを '''Setup mode''' にしてください。これはデバイスごとに異なります。

ログインし直したら、セキュアブートの状態を確認してください:

$ sbctl status

sbctl がインストールされておらず、セキュアブートが無効化されていることを確認できるはずです。

次に、カスタムのセキュアブート鍵を作成してください:

# sbctl create-keys

あなたの鍵を Microsoft の鍵と一緒に UEFI に登録してください:

# sbctl enroll-keys -m

{{Warning|一部のファームウェアは Microsoft の鍵で署名されており、セキュアブートが有効化されると Microsoft の鍵によって検証されます。デバイスが検証できないと、そのデバイスが文鎮化してしまう可能性があります。Microsoft の鍵抜きであなたの鍵を登録するには、{{ic|# sbctl enroll-keys}} を実行してください。ただし、あなたが何をしようとしているのか理解している場合に限り、これを行ってください。}}

{{Note|一部のPC（例えばFrameworkノートPC）では、ファームウェアのアップグレードやOEM提供のブートアプリケーションの実行機能を維持したい場合は、OEMファームウェアの組み込み証明書も含めることをお勧めします。この場合、代わりに以下を実行してください: {{ic|sbctl enroll-keys -m -f}} }}

セキュアブートの状態を再び確認してください:

$ sbctl status

sbctl がインストールされているはずです。しかし、あなたの鍵でブートファイルを署名するまで、セキュアブートは動作しません。

===== 署名 =====

セキュアブートを動作させるために署名が必要なファイルを確認します：

# sbctl verify

次に、署名されていないすべてのファイルに署名します。通常、[[カーネル]]と[[ブートローダー]]には署名が必要です。例えば：

# sbctl sign -s /boot/vmlinuz-linux
# sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI

署名が必要なファイルは、システムのレイアウト、カーネル、ブートローダーによって異なります。

{{Tip|特に Windows とデュアルブートしている場合は、署名する必要のあるファイルが多い場合があります。[[sed]] を使えば、sbctl によるファイルの署名を全て済ませることができます:

# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e'

この例では、出力されたファイルのパスが {{ic|/boot}} からの相対パスであると仮定しています。
}}

これで完了です! システムを再起動し、ファームウェアの設定でセキュアブートをオンに戻してください。ブートローダーとOSがロードされれば、セキュアブートは機能しているはずです。以下のコマンドで確認してください:

$ sbctl status

===== pacman フックを使って自動的に署名する =====

sbctl には、[[カーネル|Linux カーネル]]、[[systemd]]、[[ブートローダー]]がアップデートされたときに自動的にすべての新規ファイルを署名する [[pacman フック]]が同梱されています。

{{Tip|[[Systemd-boot]] と {{ic|systemd-boot-update.service}} を使用している場合、[[ブートローダー]]は再起動後にしかアップデートされないので、sbctl の [[pacman フック]]はその新しいファイルを署名しません。回避策としては、{{ic|/usr/lib/}} 内の[[ブートローダー]]を直接署名すると良いかもしれません。{{ic|bootctl install}} と {{ic|update}} は自動的に、通常の ''.efi'' ではなく ''.efi.signed'' ファイルを認識し、[[ESP]] にコピーします。{{man|1|bootctl}} を参照してください。

# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

}}

==== 手動による手順 ====

===== efitools をインストールする =====

以下のほぼ全てのセクションで、{{Pkg|efitools}} パッケージが[[インストール]]されている必要があります。

===== 鍵の生成 =====

鍵を生成するには以下の手順を行ってください:

秘密鍵と複数の形式の証明書を作成する必要があります:

; {{ic|.key}}: EFI バイナリと EFI 署名リストの署名に必要な PEM 形式の''秘密''鍵。
; {{ic|.crt}}: {{man|1|sbsign}}、{{man|1|sbvarsign}}、{{man|1|sign-efi-sig-list}} で必要な PEM 形式の証明書。
; {{ic|.cer}}: ファームウェアが使用する DER 形式の証明書。
; {{ic|.esl}}: {{man|1|sbvarsign}} や {{man|1|efi-updatevar}}、''KeyTool''、ファームウェアのための EFI 署名リストの証明書。
; {{ic|.auth}}: {{man|1|efi-updatevar}} や ''sbkeysync''、''KeyTool''、ファームウェアのための認証ヘッダが付いた EFI 署名リストの証明書 (つまり、署名済みの証明書アップデートファイル)。

所有者を識別する [[Wikipedia:Globally unique identifier|GUID]] を作成してください:

$ uuidgen --random > GUID.txt

Platform key:

$ openssl req -newkey rsa:4096 -noenc -keyout PK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Platform Key''/" -out PK.crt
$ openssl x509 -outform DER -in PK.crt -out PK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth

"User Mode" で Platform Key を削除できるようにするために空のファイルを署名してください:

$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null noPK.auth

Key Exchange Key:

$ openssl req -newkey rsa:4096 -noenc -keyout KEK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Key Exchange Key''/" -out KEK.crt
$ openssl x509 -outform DER -in KEK.crt -out KEK.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth

Signature Database key:

$ openssl req -newkey rsa:4096 -noenc -keyout db.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Signature Database key''/" -out db.crt
$ openssl x509 -outform DER -in db.crt -out db.cer
$ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth

====== ヘルパースクリプト ======

便利なヘルパースクリプトがこのトピックの参照メージの著者により提供されています[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys]([[python]] が必要です)。簡単に編集されたバージョンも {{AUR|sbkeys}} としてパッケージングされています。

スクリプトを使うには、安全な場所にフォルダを作成し(例えば、後で {{AUR|sbupdate-git}} を使ってユニファイドカーネルイメージを作成し署名する予定なのであれば {{ic|/etc/efi-keys/}})、スクリプトを実行してください:

# mkdir /etc/efi-keys
# cd !$
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh
# chmod +x mkkeys.sh
# ./mkkeys.sh
''鍵に埋め込む Common Name を入力 (例: "Secure Boot")''

これは様々な形式で必要なファイルを生成します。

===== ファームウェアに鍵を登録する =====

'''db'''、'''KEK'''、'''PK''' 証明書を登録するには、以下に述べる方法のうち1つを使ってください。

{{Tip|'''dbx''' (forbidden signatures db) は空なので、以下の手順では省いても安全です。}}

{{Warning|Platform Key を登録するとセキュアブートは "Setup Mode" から "User Mode" になります。なので、Platform Key は最後に登録する必要があります。}}

====== sbkeysync を使う ======

{{Pkg|sbsigntools}} をインストールしてください。そして、以下のディレクトリ構造を持つ {{ic|/etc/secureboot/keys}} ディレクトリを作成してください:

/etc/secureboot/keys
├── db
├── dbx
├── KEK
└── PK

例えば、以下のように:

# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}

そして、先程生成した ''.auth'' ファイルをそれぞれの場所にコピーしてください(例えば、{{ic|PK.auth}} は {{ic|/etc/secureboot/keys/PK}} へといった感じです)。

{{ic|sbkeysync}} がシステムの UEFI に加える変更を確認したい場合は、以下を使用してください:

# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose

最後に、{{ic|sbkeysync}} を使って鍵を登録してください。

# sbkeysync --keystore /etc/secureboot/keys --verbose
# sbkeysync --keystore /etc/secureboot/keys --verbose --pk

{{Tip|
* {{ic|sbkeysync}} で書き込みエラーが発生した場合、{{ic|sbkeysync}} のコマンドの前にまず {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} を実行して、ファイルの属性を一時的に変更してください。これで、{{ic|efivars}} ディレクトリ内の EFI 鍵を書き込むことができます。{{man|1|chattr}} を参照してください。
* {{ic|PK.auth}} で {{ic|permission denied}} エラーが発生する場合、次のコマンドでその鍵を登録できます: {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}
* これに失敗する場合は、ファームウェアがBIOS設定をロックしている可能性があります。DellまたはLenovoシステムでは、BIOSパスワードのリセットが必要になる場合があります。[https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-firmware-attributes-authentication sysfs firmware authentication documentation] を参照してください。

Lenovo システムの場合:

# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
'''^D'''

Dell システムの場合:

# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
'''^D'''

その後、もう一度試してください。
}}

次の起動時に、UEFI は User Mode に戻り、セキュアブートポリシーを強制するはずです。

====== ファームウェアのセットアップユーティリティを使う ======

[[FAT]] でフォーマットされたファイルシステム ([[EFI システムパーティション]] が使えます) に '''{{ic|noPK.auth}} ファイルを除いて''' {{ic|*.cer}}、{{ic|*.esl}}、{{ic|*.auth}} をすべてコピーしてください。

{{Warning|'''{{ic|noPK.auth}} を [[EFI システムパーティション]] (ESP) にコピーしないでください!''' そうしてしまうと、例えば誰かがあなたの PC を盗んだ場合に、その人が EFI セキュアブートファームウェア内のあなたの Platform Key を削除し、"Setup Mode" を有効化して、セキュアブート鍵(PK, KEK, db, dbx)をその人のものに置き換えることができてしまいます。これでは UEFI セキュアブートの意味がありません。あなただけが Platform Key を置き換えられるようにするべきです。なので、あなたの以外の人が {{ic|noPK.auth}} ファイルにアクセスできないようにするべきなのです。以上の理由から、{{ic|noPK.auth}} ファイルは、あなただけがアクセスできる秘密の安全な場所に保管してください。{{ic|noPK.auth}} ファイルの保管場所として安全なのは:

* {{ic|KeyTool}} を使用している場合は、'''[[EFI システムパーティション]]のある外部 USB スティック'''。残念ながら、{{ic|KeyTool}} は、暗号化されていないストレージからしかファイルを読み出すことができません。
* {{ic|sbkeysync}} を使っている場合は、[[保存データ暗号化|PC 上の暗号化されているストレージ]]。
UEFI 仕様に従って PC 上の [[EFI システムパーティション]]は暗号化されていてはならず、(あなたの PC が盗まれた場合や、ハードドライブが抜き取られて他の PC に接続された場合に)他の PC 上でマウントかつ読み込み可能です。また、{{ic|noPK.auth}} ファイルをあなたの PC の [[ESP]] にコピーして、後で削除することも推奨されません。なぜなら、FAT32 の [[EFI システムパーティション]]上で削除されたファイルは、[[ファイルリカバリ#Testdisk と PhotoRec|PhotoRec のようなツールで復元できてしまう]]からです。
}}

ファームウェアのセットアップユーティリティを起動し、'''db'''、'''KEK'''、'''PK''' 証明書を登録してください。ファームウェアのインターフェイスは様々です。鍵を登録する方法の例は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#setuputil Replacing Keys Using Your Firmware's Setup Utility] を見てください。

使用するツールがサポートしていれば、''.cer'' よりも ''.auth'' と ''.esl'' を使用することを推奨します。

====== KeyTool を使う ======

{{Out of date|{{Pkg|efitools}} 1.9.2-6 では EFI バイナリは同梱されなくなりました。これは、[https://gitlab.archlinux.org/archlinux/packaging/packages/efitools/-/issues/3 archlinux/packaging/packages/efitools#3] のメンテナーに提起されました。}}

{{ic|KeyTool.efi}} は {{Pkg|efitools}} パッケージに含まれています。それを ESP にコピーしてください。鍵を登録した後にこのツールを使うには、{{ic|sbsign}} で署名してください。

# sbsign --key db.key --cert db.crt --output ''esp''/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi

ファームウェアのセットアップユーティリティかブートローダか [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]]を使って {{ic|KeyTool-signed.efi}} を起動して、鍵を登録してください。

KeyTool メニューオプションの説明は [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] を見てください。

===== EFI バイナリに署名する =====

''セキュアブート''を有効化(つまり "User Mode" に)すると、署名した EFI バイナリ(例: アプリケーション、[[Unified Extensible Firmware Interface#UEFI ドライバ|ドライバ]]、[[ユニファイドカーネルイメージ]])しか起動できなくなります。

====== sbsigntools を使う ======

{{Pkg|sbsigntools}} を[[インストール]]して、{{man|1|sbsign}} で EFI バイナリに署名してください。

{{Tip|
* バイナリが署名されたかどうか確認したり署名を一覧表示したりするには: {{ic|$ sbverify --list ''/path/to/binary''}}。
* [[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトで rEFInd EFI バイナリを署名し、[[ESP]] へ db 証明書と一緒にコピーできます。手順は [[rEFInd#自分の鍵を使う]] を見てください。
}}

{{Note|''sbsign'' を {{ic|--output}} 無しで実行すると、出力されるファイルは {{ic|''filename''.signed}} となります。詳細は {{man|1|sbsign}} を見てください。}}

カーネルとブートマネージャに署名するには、''sbsign'' を使用してください。例えば:

# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key db.key --cert db.crt --output ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/BOOTx64.EFI

{{Warning|カーネル以外を署名しなかったら initramfs を改ざんから守ることはできません。''sbsign'' で手動で署名できる結合イメージを生成する方法は[[ユニファイドカーネルイメージ]] を見てください。}}

====== mkinitcpio のポストフックでカーネルに署名する ======

[[mkinitcpio#ポストフック|mkinitcpio ポストフック]] を使って、initramfs の生成時にカーネルイメージに署名することもできます。

以下のファイルを[[作成]]し、[[実行可能属性]]を付与してください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''db.key ''/path/to/''db.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|''/path/to/''db.key}} と {{ic|''/path/to/''db.crt}} の部分は、カーネルの署名に使用するキーペアへのパスに置き換えてください。

systemd-boot を使用する場合、この手順を半自動的に行う[[systemd-boot#自動で更新|専用の pacman フック]]が存在します。

====== mkinitcpio のポストフックでユニファイドカーネルイメージに署名する ======

[[ユニファイドカーネルイメージ#セキュアブート用の UKI への署名]] 章を参照してください。

===== sbupdate による完全に自動化されたユニファイドカーネルの生成と署名 =====

{{Out of date|''sbupdate'' [https://github.com/andreyv/sbupdat アップストリームリポジトリ]{{Dead link|2024|07|30|status=404}}は 2023 年 8 月時点でアーカイブされています。''sbupdate'' が作成されたのは、[[mkinitcpio]] やその他の [[initramfs]] ジェネレータに[[ユニファイドカーネルイメージ]]の生成機能が追加されて以前は面倒であった作業が非常に簡単になる前です。今日では、[[#sbctl でより簡単に行う]] にあるように sbctl を使用することを検討してください。}}

[https://github.com/andreyv/sbupdate sbupdate] は、Arch Linux でユニファイドカーネルイメージの生成と署名を自動化するために特別に作られたツールです。このツールは、[[pacman フック]]を通してカーネルのインストール・削除・アップデートを処理します。

{{AUR|sbupdate-git}} をインストールして、プロジェクトのホームページにある手順に従って設定してください。[https://github.com/andreyv/sbupdate#sbupdate]

{{Tip|[[systemd-boot]] を使用している場合、設定の必要とせずにに署名済みのカーネルイメージを直接認識させるために {{ic|1=OUT_DIR="EFI/Linux"}} を設定してください。{{man|7|systemd-boot|FILES}} と [[Systemd-boot#ローダーの追加]] を参照してください。}}

設定したら、イメージを生成するために {{ic|sbupdate}} を root として実行してください。

{{Note|''sbupdate'' の出力にはしばしばエラーを含んでいます(例えば {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}})。これらは無害で、安全に無視できます。[https://github.com/andreyv/sbupdate/issues/30]}}

==== 鍵をアップデートする ====

一度セキュアブートを "User Mode" にしたら、KEK, db, dbx を変更するには上位の鍵による署名が必要です。

例えば、db 鍵を新しいものに置き換えたい場合:

# [[#鍵を作成する|新しい鍵を作成]]
# EFI 署名リストに変換
# EFI 署名リストに署名
# 署名された証明書アップデートファイルを登録

$ cert-to-efi-sig-list -g "$(< GUID.txt)" ''new_db''.crt ''new_db''.esl
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

db 鍵を置き換えるかわりに Signature Database に別の鍵を'''追加'''したい場合、{{ic|-a}} オプションを使う必要があります ({{man|1|sign-efi-sig-list}} を参照):

$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth

{{ic|''new_db''.auth}} が作成されたら[[#ファームウェアに鍵を登録する|登録]]してください。

==== 他のオペレーティングシステムとデュアルブートする ====

===== Microsoft Windows =====

"Microsoft Windows Production PCA 2011" 鍵を UEFI セキュアブート変数に登録しない場合、[[#鍵を作成する|カスタム、個人の鍵]]で Windows のブートローダー ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) を署名しても、Windows を起動することは通常'''不可能'''です:

* {{ic|bootmgfw.efi}} に "Microsoft Windows Production PCA 2011" とあなたの独自のセキュアブート db 鍵の'''両方'''の署名 (つまり、'''2つの署名''') が含まれている場合、''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' のような UEFI ファームウェア実装は、{{ic|bootmgfw.efi}} を起動せず、セキュリティ違反エラー ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}''') を発生させます: このような UEFI ファームウェア実装は、おそらく'''1番目'''の署名だけは読み込むことができるでしょうが、'''2番目'''の署名は無理でしょう。2番目の署名の証明書だけが UEFI セキュアブート変数に登録されているので、セキュアブートの検証が失敗するのです。
* {{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 証明書が strip/削除されていて、さらにあなたの独自のセキュアブート db 鍵の署名だけがそのファイルに追加されている場合、UEFI はそのファイルを起動するでしょう。しかし、Windows はリカバリ/回復環境を起動してしまいます: Windows は Windows 環境が破損していると報告するでしょう ({{ic|bootmgfw.efi}} ファイルの "Microsoft Windows Production PCA 2011" 署名が存在しないからです)。

なので、[[Windows と Arch のデュアルブート|Windows とデュアルブート]]するには

* 選択肢1: {{ic|bootmgfw.efi}} のハッシュを {{ic|db}} 変数の許可ハッシュリストに追加する必要があります。そして、Windows アップデートが {{ic|bootmgfw.efi}} を変更するたびに毎回 {{ic|db}} 変数をアップデートする必要があります。これはかなり面倒くさいうえ、エラーが発生しやすく、Microsoft によってサポートされている方法ではありません。さらに、このようなセットアップでは Bitlocker は正しく動作しないでしょう (Windows パーティションを復号化するために毎回 Bitlocker が回復パスワードを尋ねてきます)。
* 選択肢2: Micosoft の証明書を UEFI セキュアブート変数に追加する必要があります。[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft は4つの db 証明書と2つの KEK 証明書を持っています] ([https://learn.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11#14-signature-databases-db-and-dbx 日本語訳ページ]):

** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] は、Windows OS をロードできるようにするために、{{ic|db}} 変数に含めなければなりません。
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] (別名、Microsoft 3rd Party UEFI CA 証明書) は、UEFI ドライバやオプションの ROM、{{Pkg|shim}} などのサードパーティのバイナリを使用するために、{{ic|DB}} 変数に含める必要があります。
** [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 証明書]と[https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] は、「{{ic|dbx}} の更新による不良イメージの失効の有効化と、新しい署名済み Windows イメージの準備のために {{ic|db}} を更新するために」、{{ic|KEK}} 変数に含める必要があります。しかし、Windows はこれらの証明書無しでも起動します。

Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使用して Microsoft の DER 形式 {{ic|db}} 証明書の EFI Signature Lists を作成し、それらのリストを1つのファイルにまとめてください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt'
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt'
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): Microsoft の GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) を使って Microsoft の DER 形式 {{ic|KEK}} 証明書の EFI Signature List を作成してください:

$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt'
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl

{{ic|db}} 変数のアップデートを {{ic|KEK}} を使って署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|db}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth

任意 (Microsoft の UEFI セキュアブート要件を厳密に満たすために): {{ic|KEK}} 変数のアップデートを {{ic|PK}} で署名してください。{{ic|sign-efi-sig-list}} を {{ic|-a}} オプションで使用してください ({{ic|-a}} オプションは {{ic|KEK}} 証明書を置き換えるのではなく '''追加''' します):

$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth

[[#ファームウェアに鍵を登録する]] に従い、UEFI セキュアブートデータベース変数に {{ic|add_MS_db.auth}} を登録してください。Microsoft の UEFI セキュアブート要件を厳密に満たしたい場合は、{{ic|add_MS_Win_KEK.auth}} も登録してください。

=== 署名済みのブートローダを使う ===

署名済みのブートローダーを使うというのは Microsoft の鍵で署名されたブートローダーを使うということです。署名済みのブートローダーとしては PreLoader と shim が存在します。どちらも他の EFI バイナリ (通常の[[ブートローダー]]) をチェインロードします。Microsoft は未署名のあらゆるバイナリを自動起動するブートローダーに署名しないことになっているため、PreLoader と shim は Machine Owner Key リストと呼ばれるホワイトリストを使っています。バイナリの SHA256 ハッシュあるいはバイナリの署名鍵が MokList に存在する場合、バイナリが起動されますが、存在しない場合はハッシュや鍵を登録するための鍵管理ユーティリティが起動します。

{{Warning|Microsoft が "Secured-core PC" と呼ぶものには Microsoft 3rd Party UEFI CA 証明書 (Microsoft Corporation UEFI CA 2011 または Microsoft UEFI CA 2023) が登録されていません。[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot] ([https://learn.microsoft.com/ja-jp/windows/security/information-protection/secure-the-windows-10-boot-process#%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88 日本語訳ページ])。唯一登録されている DB 証明書は Microsoft Windows Production PCA 2011 証明書で、これは Windows ブートローダーを署名するためだけに使用されます。

Microsoft 3rd Party UEFI CA 証明書で署名された EFI バイナリや OpROM を起動するには、Microsoft 3rd Party UEFI CA 証明書の登録をファームウェアの設定で有効化する必要があります。
}}

==== PreLoader ====

起動時に PreLoader は {{ic|loader.efi}} を実行しようとします。MokList に {{ic|loader.efi}} のハッシュが存在しない場合、PreLoader は {{ic|HashTool.efi}} を起動します。HashTool で起動したい EFI バイナリのハッシュ、つまり[[ブートローダー]] ({{ic|loader.efi}}) とカーネルを登録する必要があります。

{{Note|バイナリ (ブートローダーやカーネル) をアップデートするたびに新しいハッシュの登録が必要です。}}

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd と PreLoader EFI バイナリを ESP にコピーできます。手順は [[rEFInd#PreLoader を使う]] を見てください。}}

===== PreLoader をセットアップする =====

{{Note|{{Pkg|efitools}} パッケージに含まれている {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} は署名されていないため、使い道は限られています。署名済みの {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を入手するには {{AUR|preloader-signed}} をインストールするか [https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/ 手動でダウンロード] します。}}

{{AUR|preloader-signed}} パッケージを[[インストール]]して {{ic|PreLoader.efi}} と {{ic|HashTool.efi}} を[[ブートローダー]]のディレクトリにコピーしてください。[[systemd-boot]] の場合、以下を実行:

# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi ''esp''/EFI/systemd

そしてブートローダーのバイナリをコピーして {{ic|loader.efi}} に名前を変更します。[[systemd-boot]] の場合、以下を実行:

# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/systemd/loader.efi

最後に、{{ic|PreLoader.efi}} を起動する NVRAM エントリを新しく作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi

{{ic|X}} は [[EFI システムパーティション]]のドライブ文字に、{{ic|Y}} は同じくパーティション番号に置き換えてください。

上記のエントリは起動リストの一番最初に追加する必要があります。{{ic|efibootmgr}} コマンドで確認して、必要であればブートローダーの設定を変更してください。

====== フォールバック ======

カスタム NVRAM エントリの起動に問題が発生する場合、{{ic|HashTool.efi}} と {{ic|loader.efi}} を UEFI によって自動的に起動されるデフォルトのブートローダーの場所にコピーしてください:

# cp /usr/share/preloader-signed/HashTool.efi ''esp''/EFI/BOOT/
# cp ''esp''/EFI/systemd/systemd-bootx64.efi ''esp''/EFI/BOOT/loader.efi

{{ic|PreLoader.efi}} を上書きコピーして、名前を変更します:

# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/BOOT/BOOTx64.EFI

Windows にしか対応しない非協力的な UEFI 実装の場合、{{ic|PreLoader.efi}} を Windows で使用されるデフォルトローダーの場所にコピーしてください:

# mkdir -p ''esp''/EFI/Microsoft/Boot
# cp /usr/share/preloader-signed/PreLoader.efi ''esp''/EFI/Microsoft/Boot/bootmgfw.efi

{{Note|Windows とデュアルブートする場合、元の {{ic|bootmgfw.efi}} はバックアップしておいてください。ファイルを置き換えると Windows のアップデートで問題が発生する可能性があります。}}

上と同じように、{{ic|HashTool.efi}} と {{ic|loader.efi}} を {{ic|''esp''/EFI/Microsoft/Boot}} にコピーしてください。

セキュアブートを有効にした状態でシステムを起動したら、上のセクションの手順に従って {{ic|loader.efi}} と {{ic|/vmlinuz-linux}} (あるいは使用している他のカーネルイメージ) を登録します。

===== 起動途中で使用するには? =====

{{ic|Failed to Start loader... I will now execute HashTool.}} というメッセージが表示されるでしょう。{{ic|loader.efi}} と {{ic|vmlinuz.efi}} のハッシュを登録するために HashTool を使用するには、以下の手順を踏んでください。以下の手順では、リマスタリングされた archiso インストールメディアのタイトルについて仮定をおいています。実際のタイトルはブートローダのセットアップに依存します。

* ''OK'' を選択してください
* HashTool のメインメニューで、''Enroll Hash'' を選択し、{{ic|\loader.efi}} を選んで ''Yes'' で確定してください。再び ''Enroll Hash'' と {{ic|archiso}} を選択し archiso のディレクトリに入って、{{ic|vmlinuz.efi}} を選択し、''Yes'' で確定してください。そして、''Exit'' を選択してブートデバイスの選択メニューに戻ってください。
* ブートデバイスの選択メニューで、''Arch Linux archiso x86_64 UEFI CD'' を選んでください。

===== 登録したハッシュを削除する =====

MOK データベースに登録されたハッシュのエントリは NVRAM の容量を少し圧迫します。空き容量を増やしたり、時代遅れなプログラムが起動しないようにしたりするために、場合によっては使用しないハッシュを削除する必要があるでしょう。

{{Pkg|efitools}} を[[インストール]]し、{{ic|KeyTool.efi}} をコピーしてください:

# cp /usr/share/efitools/efi/KeyTool.efi ''esp''/EFI/systemd/KeyTool.efi

PreLoader を起動するよう設定すれば、KeyTool のエントリが現れます。これで、MOK データベース内のハッシュを編集することができます。

===== PreLoader を除去する =====

{{Note|以下を実行する前にバックアップを作成すると良いでしょう。}}

{{AUR|preloader-signed}} を[[アンインストール]]し、コピーしたファイルを削除して、設定を元に戻します。[[systemd-boot]] の場合、以下を実行:

# rm ''esp''/EFI/systemd/{PreLoader,HashTool}.efi
# rm ''esp''/EFI/systemd/loader.efi
# efibootmgr --unicode --bootnum ''N'' --delete-bootnum
# bootctl update

{{ic|N}} は {{ic|PreLoader.efi}} を起動するために作成した NVRAM のブートエントリに置き換えてください。{{ic|efibootmgr}} コマンドで確認を行なって、必要に応じてブート順序を修正してください。

{{Note|上記のコマンドは一番簡単な場合です。他にもファイルを作成したり、コピーしたり、ファイル名を変更したり、編集したりした場合、おそらくそれらも処理する必要があります。PreLoader をブートエントリとして使用していた場合、明らかに[[#セキュアブートを無効化する]]必要もあります。
}}

==== shim ====

起動時に shim は {{ic|grubx64.efi}} を実行しようとします。MokList に {{ic|grubx64.efi}} のハッシュあるいは署名鍵が存在しない場合、shim は {{ic|mmx64.efi}} を起動します。MokManager で起動したい EFI バイナリ ([[ブートローダー]] ({{ic|grubx64.efi}}) とカーネル) のハッシュか署名鍵を登録する必要があります。

{{Note|
* [[#shim でハッシュを使う]] を使う場合、バイナリ(例: ブートローダやカーネル)を更新するたびに、新しいハッシュをを登録する必要があります。
* バージョン 15.3 以降、shim は、有効な {{ic|.sbat}} セクションが無いと EFI バイナリを起動しません。EFI バイナリが {{ic|.sbat}} セクションを持っているか確認するには、{{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} を実行してください。詳細は [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT ドキュメント] を見てください。
* セキュアブートがもたらすセキュリティには興味がなく、Windows 11 の要件のためだけにセキュアブートを有効化する場合、{{ic|mokutil --disable-validation}} で shim の認証プロセスを無効化すると良いかもしれません。その場合、grub(sbat は依然として必要でしょう)やカーネルイメージを署名する必要はありません。それと同時に、grub の {{ic|chainloader}} で Windows を起動することができます。
}}

===== shim をセットアップする =====

{{Tip|[[rEFInd]] ブートマネージャの {{ic|refind-install}} スクリプトは rEFInd EFI バイナリを署名することができ、shim や MOK 証明書と一緒にバイナリを ESP にコピーできます。手順は [[rEFInd#shim を使う]] を見てください。}}

{{AUR|shim-signed}} を[[インストール]]してください。

現在の[[ブートローダー]]の名前を {{ic|grubx64.efi}} に変更してください。デフォルトでは、Shim は {{ic|grubx64.efi}} という名前のファイルをロードして実行しようとします。shim へのコマンドライン引数として別の EFI バイナリへのファイルパスを渡すことによってデフォルトを上書きできますが、一部のファームウェアではコマンドライン引数を持つ UEFI ブートエントリに問題があるため、デフォルトに頼る方が確実です:

# mv ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/grubx64.efi

''shim'' と ''MokManager'' を ESP 上のブートローダーのディレクトリにコピーしてください; {{ic|shimx64.efi}} はブートローダの以前のファイル名を使ってください:

{{Note|有効な {{ic|bootx64.csv}} が存在しない限り、{{ic|fbx64.efi}} (同じディレクトリ内にあります) はコピー'''しない'''でください。さもないと、shim は {{ic|grubx64.efi}} を'''実行せず'''、動作に失敗してマシンをリセットします。}}

# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI
# cp /usr/share/shim-signed/mmx64.efi ''esp''/EFI/BOOT/

最後に、{{ic|BOOTx64.EFI}} を起動する新しい NVRAM エントリを作成してください:

# efibootmgr --unicode --disk /dev/sd'''''X''''' --part '''''Y''''' --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI

''shim'' は、MokList に格納されている Machine Owner Key やハッシュによってバイナリを認証することができます。

; Machine Owner Key (MOK): EFI バイナリに署名するためにユーザが生成し利用する鍵
; hash: EFI バイナリの SHA256 ハッシュ

ハッシュを用いるのは単純ですが、ブートローダやカーネルをアップデートするたびに、MokManager 内のそれらのハッシュを追加する必要があります。MOK では鍵を一度追加するだけで済みますが、ブートローダとカーネルをアップデートするたびに、それらに署名する必要があります。

====== shim でハッシュを使う ======

''shim'' は、MokList に {{ic|grubx64.efi}} の SHA256 ハッシュが存在しない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll hash from disk'' を選択してから {{ic|grubx64.efi}} を探して MokList に追加してください。同じようにカーネルの {{ic|vmlinuz-linux}} も追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動してカーネルが起動します。

====== shim で鍵を使う ======

{{Pkg|sbsigntools}} をインストールしてください。

以下のファイルが必要です:

; {{ic|.key}}: EFI バイナリに署名するための PEM 形式の''秘密''鍵。
; {{ic|.crt}}: ''sbsign'' で使うための PEM 形式の証明書。
; {{ic|.cer}}: ''MokManager'' で使うための DER 形式の証明書。

Machine Owner Key を作成:

$ openssl req -newkey rsa:2048 -nodes -keyout MOK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Machine Owner Key''/" -out MOK.crt
$ openssl x509 -outform DER -in MOK.crt -out MOK.cer

{{Note|shim は 4096 RSA キーを MokList に追加できないようです ({{ic|grubx64.efi}} バイナリをロードして検証する際にフリーズするかもしれません)。なので、今の時点では 2048 キーを使用してください。[[Debian:SecureBoot#Generating a new key]] を参照してください。}}

({{ic|grubx64.efi}} という名前の) ブートローダーとカーネルに署名:

# sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi

ブートローダーとカーネルをアップデートするたびに上記の署名が必要です。カーネルの署名は [[mkinitcpio#ポストフック|mkinitcpio ポストフック]] で自動化できます。以下のファイルを[[作成]]し、[[実行可能属性|実行可能]]にしてください:

{{hc|/etc/initcpio/post/kernel-sbsign|2=
#!/usr/bin/env bash

kernel="$1"
<nowiki>[[ -n "$kernel" ]] || exit 0

# use already installed kernel if it exists
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki>

keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt)

for (( i=0; i<${#keypairs[@]}; i+=2 )); do
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}"
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel"
fi
done
}}

{{ic|MOK.cer}} を FAT でフォーマットされたファイルシステムにコピーしてください ([[EFI システムパーティション]] を使うことができます)。

再起動してセキュアブートを有効にしてください。''shim'' は MokList に {{ic|grubx64.efi}} を署名するときに使った証明書がない場合、{{ic|mmx64.efi}} を起動します。

''MokManager'' で ''Enroll key from disk'' を選択してから {{ic|MOK.cer}} を探して MokList に追加してください。完了したら ''Continue boot'' を選択してください。ブートローダーが起動して、Machine Owner Key で署名されたバイナリを起動できるようになります。

====== shim で鍵と GRUB を使う ======

手順は [[GRUB#Shim-lock]] を見てください。

===== 登録されたハッシュ/鍵を削除する =====

MOK データベースに登録されたハッシュ/鍵のエントリは、NVRAM の領域を少しずつ圧迫していきます。領域を節約し、古いプログラムがブートされないようにするために、使っていないハッシュ/鍵は削除すると良いかもしれません。

MOK データベースは {{Pkg|mokutil}} で管理できます。

登録された鍵とハッシュを一覧表示する:

# mokutil --list-enrolled

データベースからハッシュを削除する。ここで入力するパスワードは、MOK マネージャで削除の確認を行う際に再び尋ねられます。

{{hc|# mokutil --delete-hash ''hash_to_remove_from_above_command''|
Input password:
}}

データベースから鍵を削除する:

# mokutil --delete MOK.cer

次回のブート時に削除されるハッシュ/鍵を一覧表示する:

# mokutil --list-delete

次回のブート時に、登録/削除するハッシュ/鍵のオプション付きで MOK マネージャが初期化されます。詳細は {{man|1|mokutil}} を参照してください。

===== shim を除去する =====

{{AUR|shim-signed}} を[[アンインストール]]して、コピーした ''shim'' と ''MokManager'' のファイルを削除してブートローダーを元の名前に戻してください。

== セキュアブートを保護する ==

マシンに物理アクセスできる者がセキュアブートを無効化してしまうことを阻止する唯一の方法は、ファームウェアの設定をパスワードで保護することです。

ほとんどの UEFI ファームウェアはそのような機能を提供します。通常、ファームウェア設定の「セキュリティ」セクションにその項目があるはずです。

== ヒントとテクニック ==

=== ISO の再パック ===

{{Pkg|libisoburn}} と {{Pkg|mtools}} を使うことで、公式のインストールイメージを展開したり、再パックしたりできます。この方法で、カスタムの鍵か署名済みのブートローダを使ってセキュアブートをサポートするイメージを作成することができます。

==== 公式の ISO をカスタムの鍵で署名する ====

ブートローダー ({{ic|BOOTx64.EFI}} と {{ic|BOOTIA32.EFI}})、カーネル、UEFI シェルを ISO から抽出し、それらを署名し、署名済みファイルを ISO に再パックすることで、カスタムの鍵で公式の ISO にセキュアブートサポートを追加できます。

まず、関連するファイルと El Torito ブートイメージを抽出してください:

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-extract /EFI/BOOT/BOOTx64.EFI BOOTx64.EFI \
-extract /EFI/BOOT/BOOTIA32.EFI BOOTIA32.EFI \
-extract /shellx64.efi shellx64.efi \
-extract /shellia32.efi shellia32.efi \
-extract /arch/boot/x86_64/vmlinuz-linux vmlinuz-linux
}}

''mkarchiso'' によって使用されている {{man|1|xorrisofs}} のオプション {{ic|-rational-rock}} は、ISO 9660 のファイルを読み取り専用にし、これは抽出後も維持されます。ファイルを書き込み可能にし、変更できるようにしましょう:

$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux

ファイルを署名してください。{{Pkg|sbsigntools}} を使って署名する場合、以下のようにできます:

$ sbsign --key db.key --cert db.crt --output BOOTx64.EFI BOOTx64.EFI
$ sbsign --key db.key --cert db.crt --output BOOTIA32.EFI BOOTIA32.EFI
$ sbsign --key db.key --cert db.crt --output shellx64.efi shellx64.efi
$ sbsign --key db.key --cert db.crt --output shellia32.efi shellia32.efi
$ sbsign --key db.key --cert db.crt --output vmlinuz-linux vmlinuz-linux

ブートローダーと UEFI シェルを {{ic|eltorito_img2_uefi.img}} にコピーしてください。これは EFI システムパーティションとして使用され、El Torito UEFI ブートイメージとしてリストアップされます。{{ic|eltorito_img2_uefi.img}} のサイズは固定されていますが、丸め/アライメントのためや予約済みセクタに対処するために ''mkarchiso'' によって 1 MiB の空き領域が追加されています。なので、署名によるサイズ増は問題にはならないはずです。

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI BOOTIA32.EFI ::/EFI/BOOT/
$ mcopy -D oO -i eltorito_img2_uefi.img shellx64.efi shellia32.efi ::/

変更された El Torito UEFI ブートイメージを使って ISO を再パックし、署名されたブートローダーのファイル、UEFI シェル、カーネルを ISO 9660 に追加してください:

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \
-map_l ./ / shellx64.efi shellia32.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

完成した {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}} を起動してみてください。

==== ブートローダを PreLoader に置き換える ====

公式の ISO イメージにセキュアブートのサポートを追加するもう一つの方法は、ブートローダを抽出し、それを [[#PreLoader]] で置き換えることです。

{{Note|ISO の GRUB EFI バイナリ ({{ic|EFI/BOOT/BOOTx64.EFI}}) は {{ic|--disable-shim-lock}} でビルドされているため、shim で使用することはできません。これは GRUB の制限であり、GRUB に shim かカスタムの署名のどちらか一方との互換性を持たせることはできますが、同時に両方との互換性を持たせることはできません。}}

まず、ブートローダと El Torito ブートイメージを抽出してください。

{{bc|
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-extract_boot_images ./ \
-cpx /EFI/BOOT/BOOTx64.EFI ./
}}

{{ic|BOOTx64.efi}} ファイルを PreLoader に置き換えてください:

{{bc|
$ mv BOOTx64.EFI loader.efi
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
}}

新しいファイルをブートイメージに追加してください:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/

最後に、変更されたブートイメージと新しいブートローダファイルを使って ISO を再パックしてください。

{{bc|
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \
-boot_image any replay \
-append_partition 2 0xef eltorito_img2_uefi.img
}}

=== オプション ROM のダイジェスト値を登録する ===

[[Wikipedia:Option ROM|オプション ROM]] (OpROM: ブート中に実行されるデバイスファームウェア) は、セキュアブートのために署名されている必要があります。さもないと、デバイスが初期化されません。たいてい、OpROM は Microsoft 3rd Party UEFI CA 証明書で署名されています。このせいで、あなた独自の鍵のみによるセキュアブートができないことがあります。代わりに、OpROM の SHA256 ダイジェスト値 (ハッシュ値) を登録することで、この問題を解決できます。

{{Warning|Microsoft 3rd Party UEFI CA 証明書を削除して必須のデバイスが初期化されなくなってしまうと、一部のデバイス (ノート PC も含む) においてはハードウェアが文鎮化してしまい、ファームウェアの設定画面にすら入れなくなって問題解決が不可能になる恐れがあります。}}

[[TPM]] のあるシステムでは、[https://docs.kernel.org/security/tpm/tpm_event_log.html TPM イベントログ]からオプション ROM の SHA256 ダイジェスト値を得ることができます。

{{Pkg|tpm2-tools}} と {{AUR|digest-to-efi-sig-list}} を[[インストール]]してください。

{{man|1|tpm2_eventlog}} を使い、{{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} から {{ic|BOOT_SERVICES_DRIVER}} のダイジェスト値を探してください。[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom]

例えば:

{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements|
...
- EventNum: 9
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''"
...
- EventNum: 10
PCRIndex: 2
EventType: EV_EFI_BOOT_SERVICES_DRIVER
DigestCount: 1
Digests:
- AlgorithmId: sha256
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''"
...
}}

探し出したそれぞれの OpROM ダイジェスト値に対する EFI 署名リストを作成するには、''digest-to-efi-sig-list'' を使用してください:

$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl

複数の OpROM がある場合は、それぞれの EFI 署名リストを1つにまとめて、単一のファイルとして署名できるようにしてください:

$ cat OpROM1.esl OpROM2.esl > OpROM.esl

EFI 署名リストに署名して、Signature Database に追加してください:

$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth

そして、[[#ファームウェアに鍵を登録する|登録してください]]。

最も危険な最後のステップは、Microsoft 3rd Party UEFI CA 証明書を Signature Database から削除することです。削除後もシステムが起動し、全てのデバイスが機能することを確認してください。

== 参照 ==

* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] tianocore による
* [[Wikipedia:ja:Unified Extensible Firmware Interface#セキュアブート]]
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] Rod Smith による
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] Rod Smith による
* [https://mjg59.dreamwidth.org/5850.html UEFI secure booting (part 2)] Matthew Garrett による
* [https://blog.hansenpartnership.com/uefi-secure-boot/ UEFI Secure Boot] James Bottomley による
* [https://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/tree/README efitools README]
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] — Free Software Foundation
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web フリーなオペレーティングシステムディストリビューションにおけるセキュアブートに関する Free Software Foundation による推奨事項]
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel の UEFI セキュアブートチュートリアル]
* [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries]
* 米国家安全保障局のドキュメント: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] 及び機密解除された [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization]
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] Jeremy Kerr による
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + Arch Linux] (2020-07)
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange)
* [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] Lennart Poettering による (2021-09-23)
* {{AUR|cryptboot}} ツールは、(セキュアブートのための) プロセス全体を簡略化し、簡単に使えるようにします。

{{TranslationStatus|Unified Extensible Firmware Interface/Secure Boot|2024-03-28|804762}}