Ubuntu 26.10(stonking)の開発; カーネル7.2採用、UEFI CA証明書のローテーション、Arm AGI CPU、開発用サンドボックス“Workshop”

stonking(Ubuntu 26.10)の開発開始が宣言され、各種計画が開始されました。現実的には現在開催中のUbuntu Summit 26.04での議論が終了し、より精緻な計画が公開されてからが本格的な稼働となるでしょう。

現時点では、次のことが宣言されています。


特に後者は、test rebuildを行って問題を叩き出す予定であることが示唆されています。


UEFI CA証明書のローテーション

業界を騒がせているMicrosoftのUEFI・KEK CA証明書(⁠「⁠UEFI 3rd party Certificate Authority (CA) 2011」と「Microsoft KEK CA 2011⁠」⁠)の期限切れについて、Ubuntuを利用している環境でも対応が必要です。



現在のUbuntuでは、デフォルトのインストールでは(利用できる環境であれば)セキュアブートを利用して構成されています。この構成においては、起動不能が起きるわけではありません。そのまま動作させることも可能です。ただし、今後、shimまわりの(つまりセキュアブート関連の)アップデーターが提供されなくなるため、「⁠OSが起動するより前」に対する攻撃への耐性を維持できなくなるかもしれません。
将来的なアップデーターの一部や、より新しいUbuntuのイメージ、具体的には2026Q4以降にリリースされるUbuntuではこれらのshimが2023年のCA証明書へ切り替わることになるため(期限切れした証明書で署名することは通常ありません⁠)⁠、これらをセキュアブート環境で利用するにはデバイス側の証明書の更新が必要です。

これらのCA証明書は、「⁠OSアップデートに組み込まれた形で提供される、ファームウェアアップデーター」の適用によって更新されます。

Ubuntuの場合、「⁠fwupdの最新版がOSアップデートの一部として配布され、ファームウェアアップデーターが起動される」(⁠あるいはsudo fwupdmgr upgradeの実行)という形で更新できるようになる予定です。「⁠fwupd 2.0.0以上が導入されていれば」デスクトップ環境やSSHログイン直後に表示されるメッセージによってファームウェアアップデートの存在が通知されます。

「fwupd 2.0.0以上が導入されているか」は、現在利用しているUbuntuのバージョンによって異なり、2026年5月時点では次の対応状況となっています。



26.04 LTS, 25.10 を利用している場合: すでにfwupd 2.0.0(以降)が含まれています。
24.04 LTS, 22.04 LTSを利用している場合: 検証が行われた後、fwupd 2.0.0(以降)が提供されます。
上記以外のUbuntuを利用している場合: snap経由でfwupd 2.0.0(以降)が提供されます。

Arm AGI CPUへの対応

Arm AGI CPUのUbuntuでのサポートについての記事が公開されています。

Arm AGI CPUは「Arm社が自社で作るArm CPU」[1]で、Arm Neoverse V3を136コア搭載するサーバー向けの大規模CPUです。「⁠空冷では8160コア、液冷では45000コア以上を1ラックで実現できる」という超高密度構成を実現できること、そして「Arm純正であること」が主なポイントです。

Ubuntu 26.04 LTS上でArm AGI CPUの利用が可能になるだけでなく、Ubuntu Certifiedな状態で利用できることが謳われており、新世代のArmワークロードを動かすために利用できそうです。


[1] Arm社はCPUメーカーですが、「⁠CPUアーキテクチャや設計図」のみを各社にライセンスするタイプのビジネスを行ってきています。この文脈においてArm AGI CPUは「Arm社初の自社CPU」ということになります。



“Workshop”による開発用サンドボックス環境

Ubuntuの「開発者向け」ツールキットに新しい仲間が加わりました。“⁠Workshop⁠”と名付けられたLXDベースのこのツールを用いることで、特定の依存関係や利用パターンを再利用できるようになります。この依存関係等の記述にはYAMLが用いられ、カスタマイズも可能です。

構造としてはLXDのラッパーとして機能するもので、「⁠YAMLによって定義された環境をプリインストールし、適切なアクセス制御を行ったLXDコンテナ」をユーザーに提供するという形で、環境整備にかかる時間を短縮することが期待されます。

アクセス制御可能なサンドボックスとしても使えるため、AIエージェントからの利用にも好適、という方向で説明が行われています。


その他のニュース

XuanTie系CPUをサポートするためのカーネルパッケージの準備が進められています。
pastebin.ubuntu.comの廃止がアナウンスされています。6月にはシャットダウンされることが予定されているため、pastebin.ubuntu.com上に重要な情報がある場合は待避を行いましょう(pastebinはそもそも一時的な情報を配置するためのサービスなので、使い方が誤っている点の反省も必要です⁠)⁠。
Azure Marketplace上でフルマネージドなkubeflowを利用できるようになりました。
“PinTheft⁠”脆弱性へのUbuntuにおける対応が公開されています。
既存のパッケージにおける「SysV Initスクリプトから自動生成されたsystemdユニットファイル」について、26.10ではサポートされないことが予告されています。古いデーモンを利用している場合は、代替となるsystemdのユニットを新規作成する必要があります。また、バグとしてのトラッキングが開始されており、もし利用しているパッケージが該当する場合は書き直し作業に協力することもできます。


注目すべきセキュリティー的な視点:証明書の管理

セキュアブート環境を安全に保持するためには、CA証明書の適切な更新、つまりトラストチェインの維持が必要です。今回はトラストストアや証明書の更新についてあらためて考えてみましょう。

まず現代のコンピューティング環境において、セキュアブートを含めた各種「信頼できる」環境、あるいはWebアクセスにおける「信頼できるサイト」の判定には証明書が用いられています。システムは証明書の妥当性を検証します。

この文脈での「証明書の妥当性」は、「⁠あるシステムにおいて、トラストストアに格納された証明書からチェインを辿ることができる」ことを意味します。しばしば問題になるCA証明書の更新、というのは、「⁠トラストストアに格納された証明書」に、新しいものを追加するという作業です(そして、その更新においてしばしば色々な混乱が発生します⁠)⁠。

なぜこうした面倒な作業が必要なのかというと、証明書の「寿命」は無限にはできないからです。有効な暗号方式によって保護されていても、十分に長い時間をかけることができれば、証明書に用いられた暗号系を数学的に破ることもできます。この問題に対して、期限を設けることでリスクを低減しているというのが現実です。

UEFI環境においては、ファームウェア上のNVRAM領域にトラストストアが構成されています。セキュアブートの文脈では複数の鍵(⁠「⁠PK = UEFI上の変数」「⁠db/dbx = セキュアブート署名データベース(とセキュアブート失効署名データベース⁠)⁠」⁠「⁠KEK = db/dbx更新用の鍵⁠」⁠)を組み合わせて管理し、「⁠期待された通りのOSが起動している」ということを保証します。一方、オペレーティングシステムの側では、OSごとに規定されたトラストストアや、ミドルウェアごとに指定されたファイルによってこれらを管理します。通常これらは(今回のUEFIのCA更新のように)ファームウェア更新やOS更新の一環で更新されます。つまり、「⁠アップデートが確実に行われている」という前提では、あまり問題が起きません(ただし、「⁠アップデートが確実に行われている」というのは、なかなかに難しい目標です⁠)⁠。

一方、HTTPSなどの文脈における証明書の管理は、「⁠証明書を利用するサービス」の管理者の仕事です。特にWeb系であれば証明書は動的に(今のところは一年おきに)更新される必要があり、有効期限や、暗号系としての有効性を監視する必要がありますまた、少なくともHTTPSで提供するWebサービス以外に、LDAPSなど、関連するであろうサービスについてもTLSに依存するケースは多々あります。

今後TLS証明書の有効期限は今後徐々に縮小されていくため(2029年3月15日には最長47日、通常は1ヶ月~1.5ヶ月周期での更新が必須になります⁠)⁠、これらを維持するための備えを行う必要もあります。証明書の入手とアップデートが十分なペースで自動化される必要があるでしょう。

つまり、健全と言い切れる環境の条件として、発行した証明書すべてについて、残期限と利用しているアルゴリズムの一覧が動的作成される仕組みが存在する必要があります。システムごとに異なる管理システムを用いていても良いのですが、「⁠特に監視はしていない」という状態であれば、ほぼ間違いなく何かしらのインシデントが起きるであろう、ということはほぼ確定的に言えそうです。

証明書の期限そのものはopenssl x509コマンドを用いたワンライナー等で取得でき、監視のための仕組みを作ることそのものは、直接的なものであれば難しくありませんし、各種モニタリングツールではたいていカバーしているはずです。あるいはAIに実装を頼むこともできるでしょう。もし現状で取得していない、あるいは自組織(これが示す範囲はさまざまです)が利用する証明書を一覧するダッシュボードが存在しないのであれば、現時点で準備を行う必要があるでしょう。