Ubuntu 26.10、GRUBから主要機能を大量削除へ
Linuxの起動を支えてきたブートローダーが、静かに骨抜きにされようとしている。その影響は、想像以上に広い。
Linuxの起動を支えてきたブートローダーが、静かに骨抜きにされようとしている。その影響は、想像以上に広い。
署名済みGRUBから消えるもの
Ubuntuの次期リリース26.10で、Secure Boot用の署名済みGRUBビルドから大量の機能が削除される提案が出ている。Canonicalのエンジニア、ジュリアン・クローデが3月25日にUbuntu Discourseへ投稿した「Streamlining secure boot for 26.10」がその震源地だ。
削除対象は広範囲にわたる。ファイルシステムではBtrfs、XFS、ZFS、HFS+のサポートが消え、残るのはext4、FAT、ISO 9660（Snap用のsquashfsを含む）のみ。パーティションテーブルではApple形式が除外され、GPTとMBRだけが残る。
さらにLVM（論理ボリューム管理）、RAID1以外のmd-raid、そしてLUKSによるディスク暗号化サポートもすべて削除される。JPEG・PNG画像のパーサーも対象だ。
つまり、Secure Bootを有効にしたUbuntu 26.10では、/bootパーティションは暗号化されていないext4上に置くしかなくなる。暗号化された/bootは不可能になり、ZFSやBtrfs上の/bootも使えない。
この変更の理由をクローデは端的に述べている。GRUBのパーサー群が「セキュリティ問題の絶え間ない発生源」であり、削減によって「セキュリティを大幅に改善」できるという主張だ。
Ubuntu 26.10 Looks To Strip Its GRUB Bootloader To The Bare Minimum For Better Security
— Phoronix (@phoronix) March 25, 2026
Removing support for ZFS, XFS, Btrfs, md-raid sans RAID1, LVM, LUKS-encrypted disks, and more for their signed GRUB builds. Basically, boot with basic EXT4 /boothttps://t.co/HtPSyKH0k7
21件のCVEが突きつけた現実
提案の背景には、2025年2月に一斉公開されたGRUB2の脆弱性群がある。CVE-2024-45774を筆頭に、じつに21件のCVEが同時に開示された。JPEGパーサーのヒープ境界外書き込み、HFSファイルシステムのstrcpyによるバッファオーバーフロー、gettextの整数オーバーフロー──攻撃面の広さは衝撃的だった。
GRUBはカーネルが起動する前に動作する。つまりLinuxカーネルのセキュリティ機構が一切効かない状態で、これだけのパーサーが走っている。Canonicalの論理は明快で、「複雑なストレージやファイルシステムのロジックはinitramfsに移すべきだ」というものだ。カーネル側のドライバのほうがはるかに厳密なセキュリティレビューを受けており、更新頻度も高い。
理屈としては筋が通っている。だが、理屈の正しさと現実の妥当性は別の話だ。
自社のインストーラーが作る構成すら動かない
この提案に対して、コミュニティの反応は激しかった。Ubuntu Discourseの投稿には1万を超える閲覧と79件以上のコメントが集まり、議論は過熱している。
最も鋭い指摘を放ったのは、Ubuntuテクニカルボードメンバーのトーマス・ウォードだ。UbuntuのサーバーインストーラーはデフォルトでLVMを使用し、Ubuntu上でのLUKS暗号化はLVMを必要とする。つまり、Canonical自身が推奨するインストール構成が、この提案の下ではSecure Bootと両立できなくなる。
Canonicalが「セキュリティのため」と言いながら、自社の標準構成を切り捨てるという矛盾。機能ごとの公開された正当化がなければ、この提案は進めるべきではない──ウォードの主張は明確だった。
FedoraやopenSUSEのコントリビューターとして知られるニール・ゴンパも複数の点で反論した。GRUBのBtrfsドライバはリードオンリーであり、上流で積極的にメンテナンスされている。boot-to-snapshot構成に依存するユーザーにとっては不可欠な機能だ。また、ソフトウェアRAID1が「一般的ではない」というクローデの見解にも異を唱え、現場では極めて一般的な構成だと指摘している。
juliank
「暗号化/bootの廃止」が招くもの
技術的な議論の中でも、とりわけ物議を醸しているのがLUKS暗号化/bootの廃止だ。
クローデは/bootの暗号化を「実質的なセキュリティではなく、隠蔽によるセキュリティに過ぎない」と述べた。TPMベースのフルディスク暗号化（FDE）のほうが正しいアプローチだという立場だ。
だが、ヨーロッパではフルディスク暗号化が法的要件となっている環境がある。/bootを暗号化できないということは、一部の企業環境でコンプライアンス上の問題を引き起こしかねない。
Hacker Newsでは別の角度から懸念が示された。暗号化されていない/bootは、攻撃者がgrub.confやカーネルコマンドラインを改ざんできることを意味する。IOMMUの無効化やカーネルモジュール署名検証の回避など、起動プロセスの早い段階で段階的にセキュリティを劣化させる攻撃経路が開かれるという指摘だ。
「セキュリティ改善」の名の下に、別のセキュリティリスクを生むという皮肉な構図が浮かび上がる。
systemd-bootという選択肢、そしてGRUBの宿命
コミュニティからは繰り返し「systemd-bootに移行すべきではないか」という声が上がっている。systemd-bootはまさにCanonicalが求めるミニマルなブートローダーであり、systemdベースのシステムとの統合も自然だ。
しかし、systemd-bootはUEFIのみ対応という根本的な制約がある。Ubuntuはx86以外のアーキテクチャもサポートするマルチアーチプラットフォームであり、UEFIもBIOSも存在しない環境向けのビルドもある。クラウドやVPS環境の多くは今なおUEFIに対応していない。20年以上前のハードウェアの話ではなく、現在進行形の制約だ。
GRUBを捨てられないから、GRUBを骨抜きにする。「同じブートローダーを維持しつつ、ユーザーが依存している知性を剥ぎ取る」という中途半端な着地点に、コミュニティの不満が集中している。
なお、影響を受ける構成のシステムは26.10へのアップグレードが自動で無効化され、26.04 LTS（10年サポート）にとどまる設計だ。セーフティネットとしては妥当だが、問題の先送りでもある。
削るべきは本当にここなのか
この提案はまだ最終決定ではない。しかし、議論の構図は明確になってきた。
GRUBのパーサーが攻撃面であることは、21件のCVEが証明している。だが、OMG! Ubuntuが指摘したように、削除対象のBtrfsやXFSにはGRUB関連のCVEが存在しない一方、残留するsquashfsにはCVEがある。削除の基準が「実際のリスク」ではなく「Canonicalが使わない機能」に見えてしまう点は、信頼を損なう要因だ。
セキュリティの向上は正しい方向だ。だが、自社の標準インストール構成との整合性も取れず、機能ごとの具体的なリスク評価も示さないまま「大幅削除」を提案すれば、反発は避けられない。
Linuxの自由は、選択肢の多さの上に成り立っている。その選択肢を「あなたのために」と言って奪うとき、信頼のコストは思った以上に高くつく。
参照元
他参照
