Win→Linuxデュアルブート支援ツールで、GRUBにNTFSモジュール追加のため自前ビルドが必要になり未署名化。Secure Boot環境で動かす良い方法は、MOK登録以外にある?

Claude Opus 4.8

Answer: 方針は変えず、MOK登録を避けたいなら未署名の自前GRUBを通す方法を探すのではなく、署名済みGRUBで済む構成に戻すか、UEFI db等の別の信頼ストアに鍵を入れるしかありません。

他モデルの回答を見ても、Secure Bootの信頼チェーン上、未署名のEFIバイナリや未検証のGRUB構成をそのまま実行する「良い抜け道」はない、という点は一致しています。したがって私の立場は維持します。 実務上の第一候補は、NTFS対応のために自前GRUBをビルドする設計をやめることです。まずディストリビューション提供の署名済みshim/GRUBにntfs関連モジュールが組み込まれている、またはSecure Boot下で正しく利用できる形で提供されているか確認すべきです。使えるなら、それを使うのが最も安全で運用負荷も低いです。 ただし、署名済みGRUBなら常に外部の`ntfs.mod`を自由に`insmod`できる、とは一般化しない方がよいです。Secure Boot有効時のGRUBはロックダウン、モジュール検証、ディストリビューションごとのビルド方針、BootHole以後の制限に影響されます。したがって「既存の署名済みGRUBでNTFSが読めるなら使う」は有力ですが、「未署名モジュールを後から読ませればよい」とまでは言い切れません。 より堅い設計は、そもそもGRUB段階でNTFSを読まない構成です。Linuxのkernel/initrd/設定をESP、XBOOTLDR、またはLinux側の/bootに置き、WindowsはWindows Boot Managerをchainloadするだけにします。これならNTFSアクセスはLinux起動後に任せられ、Secure Bootの初期ブートチェーンを壊しません。 どうしてもNTFS対応を組み込んだ自前GRUBが必要なら、そのGRUBを信頼済み鍵で署名する必要があります。MOK以外の選択肢としては、UEFIファームウェアのdbに自前鍵を直接登録する、PK/KEK/dbを自前管理する、Microsoft UEFI CA等の署名プロセスに乗せる、といった方法があります。ただしdb直接登録やカスタムPK運用は機種依存・復旧難度・管理負荷が高く、Microsoft署名は小規模ツールには手続き面で重いです。 結論として、推奨順は、署名済み既存ブートローダでNTFS依存を避ける、必要ならMOKで自前鍵を登録する、管理端末ならUEFI dbへ鍵を入れる、最後にSecure Boot無効化です。MOKを避けつつ未署名の自前GRUBをSecure Boot環境で安全・汎用に動かす方法はありません。

GPT-5.5

Answer: 立場は維持し、MOK登録以外の「良い」汎用解は基本的に自前GRUBを避けて既存の署名済みブート経路に寄せることであり、未署名の自前GRUBをSecure Boot下で動かす抜け道はありません。

他モデルの回答を見ても、私の結論は変わりません。Secure Bootで重要なのは、GRUBがNTFSを読めるかどうか以前に、そのEFIバイナリと起動チェーンが信頼済み鍵で検証されることです。自前ビルドしたGRUBが未署名になったなら、MOK、UEFI db、カスタムPK/KEK/db、Microsoft系署名など、何らかの信頼登録なしに起動させることはSecure Bootの設計上できません。 「MOK登録」以外の現実的な候補としては、UEFIファームウェアのdbへ自前鍵を直接登録する、Secure Boot鍵一式を自前管理する、Microsoft UEFI CA等の署名プロセスに乗せる、またはSecure Bootを無効化する方法があります。ただし、db直接登録やカスタム鍵運用は機種依存・復旧難度・配布先ごとの作業負担が大きく、Microsoft署名は小規模ツールや個人用途では手続き面で重いです。Secure Boot無効化は「動く」方法ではありますが、Secure Boot環境で動かす良い方法とは言いにくいです。 一方で、Claude Opus 4.8やGLM 5.2が述べたように、自前GRUBを使わず、ディストリビューション提供の署名済みshim/GRUBで済ませる方向は妥当です。特に、署名済みGRUBにNTFS機能が既に組み込まれている、またはその構成で正式にサポートされているなら、自前ビルド自体を回避できるため最もきれいです。ただし、Claude Opus 4.6の「署名済みGRUBから`insmod ntfs`すればモジュール側署名は不要」と一般化する説明には慎重であるべきです。Secure Boot下のGRUBはBootHole以降、外部モジュールや外部設定の扱いに制限が入っている構成が多く、未検証モジュールを自由に読み込める設計はむしろ危険です。 したがって設計としては、GRUB段階でNTFSに依存しないようにするのが最善です。Linuxのkernel/initrd/設定はESP、XBOOTLDR、またはLinux側の/bootに置き、WindowsはWindows Boot Managerをchainloadするだけにする。NTFSアクセスはLinux起動後にntfs3等で扱えばよく、GRUBへNTFSモジュールを追加する必要がなくなります。 結論として、配布・支援ツールとして勧める順序は、まず署名済み既存ブートローダーで要件を満たす設計に変えること、次に必要ならMOKで自前鍵を登録して署名すること、管理対象端末ならUEFI dbへの鍵登録を検討することです。「MOK登録」を避けつつ未署名の自前GRUBをSecure Boot環境でそのまま動かす、という方向は推奨できません。

GLM 5.2 (changed mind)

Answer: MOK登録以外では、ディストリビューション提供の署名済みGRUBで`insmod ntfs`によりバンドル済みntfs.modを動的ロードする方法が最も現実的であり、それがBootHole対策で制限されている場合はWindows Boot Managerを一次ブートマネージャとしてchainloadする構成かsystemd-bootが代替となる。

Claude Opus 4.6の回答に説得され、立場を修正した。私の前回回答は「署名済みGRUBにNTFSモジュールが含まれているか確認する」という検証ステップを提示していたが、なぜモジュール側の署名が不要なのかという技術的機構の説明が不足していた。同モデルの指摘通り、署名済みgrubx64.efiはESP内の同一ディレクトリに配置された拡張モジュール（.mod）を実行時に動的ロードでき、grub.cfg内で`insmod ntfs`を記述するだけでバンドル済みntfs.modを読み込める。この場合、バイナリ本体が署名検証を通るためモジュール側の署名は不要となり、自前ビルドそのものを回避できる。多くの主要ディストリ（Ubuntu、Fedora等）のGRUBパッケージにはntfs.modが同梱されているため、実務上この経路が最も手軽である。 ただしBootHole脆弱性（CVE-2020-10713）以降、Secure Boot下でのGRUBモジュール動的ロードや外部設定ファイル読み込みを制限しているディストリも存在する。この制限に該当する場合は、Claude Opus 4.6が提示する代替案が有効である。具体的にはWindows Boot Managerを一次ブートマネージャとして使用し、bcdeditでLinux側の署名済みブートローダをchainloadする構成を採れば、GRUBがNTFSへ直接アクセスする必要性自体が消滅する。またsystemd-boot（gummiboot）はディストリ鍵で署名されshimから信頼されるため、Windows Boot Managerへのchainload経路としてSecure Boot互換の選択肢となる。 Claude Opus 4.8やGPT-5.5が指摘する「そもそもGRUBでNTFSを読む設計を避ける」方針も設計論として正しく、上記のWindows Boot Manager主体構成はまさにその方向性を実現する。UEFIファームウェアのdbへ直接鍵を登録する方法やSecure Bootの一時無効化は、私の前回回答通り残存するが、前者は機種依存・管理負荷が高く後者はセキュリティ保護を失うため、いずれも最終手段に留めるべきである。 結論として、質問の趣旨である「MOK登録以外の方法」に対しては、第一に署名済みGRUB＋`insmod ntfs`、第二にWindows Boot Manager主体のchainload構成またはsystemd-boot、が現実的な回答となる。MOK登録が汎用性・確実性で依然最良である点は他モデルと一致するが、上記代替は実環境で機能する。

Claude Opus 4.6 (changed mind)

Answer: MOK登録以外の最も推奨される方法は、GRUBがNTFSを読む必要をなくす設計変更であり、まず既存の署名済みGRUBにntfsモジュールが組み込み済みか確認し、組み込み済みならinsmodで活性化、未組み込みならLinux側ファイルをESP/FAT32に配置してWindowsはchainloadのみで起動する構成に変更すべきである。

ラウンド1で私は「署名済みGRUBがESP上の外部ntfs.modファイルをinsmodで動的ロードできる」と主張したが、GPT-5.5の指摘によりこの前提に重大な誤りがあったことを認めた。BootHole脆弱性（CVE-2020-10713）以降、Secure Boot下のGRUBはロックダウン機能により外部未署名モジュールの動的ロードを制限・禁止している場合が多く、ディストリ提供の署名済みgrubx64.efiであっても、ディスク上の外部.modファイルをinsmodで読み込むことはSecure Boot環境では期待通り動作しない可能性が高い。 正しく理解すべきは、GRUBの「組み込みモジュール」と「外部モジュール」の区別である。署名済みgrubx64.efiのバイナリ内にコンパイル時に組み込まれたモジュールはinsmodで活性化できるが、ディスク上の未署名.modファイルを読み込むことはSecure Boot下では制限される。したがってGLM 5.2が指摘した通り、まず「既存の署名済みGRUBにntfsが組み込み済みか確認する」ことが第一歩であり、組み込み済みであれば自前ビルド不要でinsmod ntfsが機能する。 しかしntfsが組み込み済みでない場合、外部.modのロードはSecure Boot下で困難となる。この場合、Claude Opus 4.8とGPT-5.5が共に主張した設計変更アプローチが正解となる。具体的にはLinux側のカーネル、initrd、GRUB設定ファイルをESP上のFAT32またはLinux側の/bootに配置し、GRUB段階でNTFS領域に依存しない構成にする。WindowsはGRUBからWindows Boot Managerをchainloadするだけで起動でき、GRUBがNTFSファイルシステムを直接読む必要はなくなる。Linux起動後にntfs3ドライバ等でNTFS領域をマウントすれば、デュアルブート用途は十分に満たされる。 以上を整理すると、推奨される検討順序は以下になる。第一に既存の署名済みGRUBでntfsが組み込み済みか確認し、組み込み済みならinsmodで対応する。第二に設計を見直し、GRUB段階のNTFS依存を排除してchainload構成に移行する。第三にどうしても自前ビルドGRUBが必要ならMOKまたはUEFI dbへの署名鍵登録が必須であり、Secure Bootの信頼チェーンを維持したまま未署名バイナリを実行する抜け道は原理上存在しない。ラウンド1の私はこの原理的な制約を過小評価していた。

Final Summary

the AI Roundtableは、MOK登録を避ける現実的な代替案を検討しました。当初、Claude Opus 4.6とGLM 5.2は署名済みGRUBでのNTFSモジュール動的ロードを提案しましたが、GPT-5.5とClaude Opus 4.8がBootHole対策によるセキュリティ制限を指摘したことで議論が発展。最終的に、自前ビルドを諦めてLinuxの起動ファイルをESP（FAT32）に配置し、GRUB段階でのNTFS依存自体を無くす設計変更が最善であると全員が合意しました。

All 4 models agreed