Ubuntu 26.10（Stonking）の開発; arm64の位置付け変更の振り返りとpollinateの廃止、upkiによる証明書失効確認

Stonking（Ubuntu 26.10）の開発; arm64の位置付け変更の振り返りとpollinateの廃止

Arm64のこの一年の進展についての整理が行われています。主な整理の内容は次の通りです。

resoluteではArm64パッケージがports.ubuntu.comからarchive.ubuntu.com経由の配布になった[1]。
Arm64向けのLivepatchがGAした。
Arm64版のSteam Snapパッケージが提供されるようになった。
Snapdragon X Eliteでセキュアブートが利用できるようになった。
CIX P1のサポートが開始された。
Arm64上のChromeにおいて、WidevineによるDRMコンテンツの再生が可能になった。
Arm64版のSnapパッケージが増えた。

また、Ubuntuにおけるpollinateの必要性についての再検討が行われています。Pollinateは「システムに乱数ソースとしての適切なエントロピーを注入する」ためのソフトウェアで、古典的なハードウェアにおいて「エントロピーの充足待ちで起動が遅くなる（特に、最初の起動におけるSSHホストキーの生成の文脈⁠）⁠」問題を解決するためのソフトウェアだったものの、ハードウェアの進化によって現在ではむしろシステムの起動を遅くし、余計な負荷を発生させてしまっているという結論から、「⁠stonkingでは廃止するべき」という結論が導かれています。

upkiによる証明書失効確認

証明書の利用においては、「⁠失効した」証明書を適切に認識する必要があります。証明書の発行においては不適切な発行が行われたり、証明局そのものの単位で「信頼に値しない」という判断のもと、証明局の単位ですべての証明書が無効と認定されたりすることがあります。これらは『まれ』なこととされていますが（業界的に「まれ」ということになっているという意味です⁠）⁠、無視できるような話でもなく、「⁠ある証明書が有効なのかどうか」を証明書の利用の前に確認する必要があります[2]。

こうした証明書の失効リストはLinuxにおいてはWebブラウザーの実装レベルで行われてきており、「⁠OSレベルで利用できる」ものは存在していませんでした。要するにFirefoxとChromeそれぞれで実装されているものの、「⁠システムにおいてTLSを利用する」シチュエーションで利用できる決定版に相当する定番のソフトウェアというものが不在で、いろいろなクライアントソフトウェアが個別に実装している（あるいは失効の確認を放棄している）という状態でした。

この「OSレベルでの失効確認のためのフレームワーク」をRustベースの実装で実現するのがupki [3]プロジェクトで、Canonicalが支援しています。CRLiteベースの失効データベースをローカルに保存し、いろいろな場面で利用できる証明書失効システムを構築することが目的とされています。

このupkiがそろそろバージョン1.0を迎えつつあり、プレビュー版がstonking、resolute向けに提供されるようになりました。現時点ではPPA経由で提供されます。将来的に「正式版」がUbuntuに投入される場合、パッチ版OpenSSLと統合される形で、「⁠OpenSSLを利用するソフトウェア」であれば無条件でupkiによる証明書失効確認が行えるようになることが示唆されています。これにより、「⁠OSレベルの」統合が「OpenSSLから呼び出される」という形で実現されます。

また、CRLiteのUbuntu的なホストとして、「⁠https://upki.ubuntu.com/revocation/」というMozilla版のミラーが存在すること、stonkingでパッチ版OpenSSLとともにリリースすることが目標であることが示されています。

なおupkiにはさらに将来の拡張として、次のようなことをターゲットにしていることが示されています。

CT（Certificate Transparency）確認の強制化。CTは「証明局が証明書を発行したログ」で、これが存在しない証明書は、現代では100%不正なものであると断定できます。CTが存在しない場合に接続を拒絶する、という動作はWebブラウザーには実装されていますが、失効確認と同様にLinuxにおいては「OSレベルの」実装が存在していませんでした。
中間証明書のプリロード。現状では「本来はサーバー側の責務である」中間証明書の提供に失敗しているケースがあまりに多いため、多くのHTTPSクライアント（Webブラウザー）は独自に中間証明書を保持し、破綻した証明書構造を持つサーバーへの接続性を提供しています。upkiでもこのような機能が保持されるようになる見込みです。これもLinuxにおいてはOSレベルの実装は存在していません。
MTC（Merkle Tree Certificates; マークルツリー証明書）のサポート。PQC（ポスト量子暗号）では署名サイズが2KBを超えることも珍しくなく、これまでの数十バイトの署名に比べて膨大な通信量が必要になります。これを毎回個別にダウンロードしているとTLS通信が開始されるまでに莫大な通信が発生してしまうため、ツリーのヘッドのハッシュのみ署名することで署名の数そのものを減らします。CTを前提条件とするため、これもLinuxにおいては「OSレベル」の実装が不在なものの一つです。

その他のニュース

カーネルの脆弱性、“⁠pedit COW⁠”と“⁠DirtyClone⁠”への対応方針が説明されています。
Workshop 0.9.3がリリースされています。refreshによってSSH鍵やマシンIDが初期化されなくなったと、SFTPへの依存がなくなったことの他、「⁠プロダクションに向けた整理」が行われているように見えます。
workshopの「workshop run test」相当のテストを「canonical/launch-workshop」を用いることでGitHub hosted Runnerで利用できるようになりました。
Ubuntu Serverの現在の機能の振り返り。主にMAASなどのCanonical製ソフトウェアとの親和性、そして仮想化とk8sのサポートについて整理されています。

注目すべきセキュリティー的な視点：暗号化シードとブロッキング処理

理想的な乱数生成は、パーソナルコンピューターでは非常に古典的なテーマです。暗号通信だけでなくゲームなどの文脈でも、「⁠完全に適切な乱数」を得るには多くの困難があります。そしてそれに劣る「ある程度適切な乱数」であっても、この15年ほどでやっとコンシューマーCPUでも使えるようになった、ということが現実です。

古典的なCPU実装、つまりRDRANDやRDSEEDといった拡張命令が利用できるようになる「前」までのPC-AT互換機の世界では、乱数は非常に貴重な資源でした。半導体ベースで動作する計算機のたぐい、特にPCにとっては、「⁠ランダムな挙動」のために使えるソースがきわめて限定的です。RDRANDやRDSEEDは、CPUノイズを利用して乱数シードを提供するための命令群です。ここで乱数を取得し、さらにここに熱や時間のたぐいをさらに加えて、疑似乱数を生成する、という仕組みでLinuxカーネルは「ランダムさ」を提供しています。

「ランダムさ」が必要な文脈であっても、ソースが十分な乱数ビットを提供できるとは限りません。そこでソフトウェア実装で、なんらかの『ランダムな』入力源、たとえば『人間のキータイプの揺れ』といったものを補助的に実装として用いることがあります。そうした入力を補助的に使いつつ、乱数ソースが『溜まる』まで処理をブロックして待つことがしばしば起きます。

この結果、昔からUnixlike OSを利用している人の多くにとっては、「⁠乱数が必要になったタイミングでランダムなキー入力が求められる」状態、つまり、「⁠隣の人がよくわからない形でキーボードを乱打しはじめた、SSHかGPGの鍵を生成しているのか、それともストレス解消かのどちらかだ」と推定することは、それほど珍しいことではありませんでした。

一方で、サーバーシステムのような「人間が介在しない」システムにおいてはこうした手段は取れないので、なんらかの形で乱数ソースを補助する必要があります。ディスクIOや各種割り込みがこれらのソースに使われていたのですが、「⁠必要になったとき」に十分な乱数ソースが蓄積されているとは限りません。そして、蓄積されていなければ「溜まるまで待つ」という形でシステムが停止することになります。この「待ち」を防ぐための仕組みのひとつがpollinateだったのですが、CPUに「ある程度適切な」乱数取得命令が実装された現在となっては「もう要らない」という結論になった（し、どうも現状としては乱数の不足によってブロッキングされるよりも複雑な処理による遅延のコストの方が大きそうだ）というのが現状です。

……ということでCPUが「ある程度適切な」乱数を提供できるようになったことで性能が良くなりました、という簡単な話であれば良いのですが、ここにはさらに「CPUベンダーが提供するCPUノイズ起因の乱数生成器は本当に信用できるとは限らない」という問題もあります。

CPUベンダーがどこかの国の意図に基づいて乱数生成器になんらかの脆弱性を仕込む可能性もありますし、自然なエラーの結果として予測可能性が提供されてしまうこともありえます。よってCPU組み込みの乱数生成器を単独で利用すると不安が残るのでそこに温度やマイクロ秒以下の時間といった物理現象を加えることで、「⁠真のランダムさ」ではないものの物理現象としての予測不可能性を追加するトレードオフが含まれています、という話を始めると無限に話が発散するので、「⁠なんとなく高度な疑似乱数が使えるらしい」という理解でいいでしょう。