stonking（Ubuntu 26.10）の開発; Snapshot 4とカーネル 7.3への切り替え、デスクトップのOOMハンドリング
stonkingのSnapshot 4がリリース されました。
通常は月末に登場するSnapshotが唐突にリリースされた印象がありますが、これはSnapshot 3のリリースアナウンスで 「We might run a surprise snapshot to test some changes to our machinery as we go live. Otherwise, be prepared for the Stonking Beta on September 24th.」（ 仕組みがgo liveできたらサプライズでスナップショットを出すかもしれません。間に合わない場合は次は9月24日のBetaです）という形で「なんとなく」匂わせていたもので、つまりは「Snapshotを出しやすくする何かの仕組み」の準備が整った、ということが推定されます。
テスト用途としてはSnapshotそのものはあまり意味がない（Snapshot 3からの経過時間が短すぎる）側面もありつつ、「 Snapshotを継続的に出し続ける」という方向の仕組みそのもののテストと思っておくのが良さそうです。
この仕組みはおそらくは既存のISO Trackerの後継となるテスト近代化の成果物 に関連するものです。成果物（リリースされるISOイメージ）の種類が増加し続ける一方、それらに対する全体的なテストカバレッジは不足しており、今後もリリースエンジニアリング全体の改善と自動化が行われることになりそうです。
なお現状では26.04からstonkingにアップグレードすると26.04環境でsudo-wsを選んでいても強制的にsudo-rsに切り替わる （つまりRust版sudoがとにかく強制される）という問題もあり、まだまだ完成までには多くの作業が必要です。
またリリースに向けた調整やBetaに向けたフリーズ が行われる横で、カーネル7.3の利用 が駆け込み的に決定されています。
stonkingでは7.2カーネルの利用が予定されていましたが、7.2がきわめてスムーズにリリースされたこと、そして7.3の開発もきわめて順調に進んでおり、ちょうどstonkingのリリースに間に合いそうなことから7.3の利用を決定した、ということが述べられています。ということで、ここからベータ・Release Candidateあたりでは（場合によってはリリース最初期にも）「 7.3-rc1」といった文字列がカーネルに含まれることになります。こうした「BetaやRelease Candidateのタイミングでのチャレンジ」はUbuntu的には「よくあること」です。
また、GNOME環境におけるOOMスコアの調整 へ向けた作業が行われています。
Ubuntu Desktop環境ではメモリ不足に陥ると、「 デスクトップを構成するGNOMEそのもの」（ GNOME Shell）やキーになるプロセス（D-BusやNetwork Managerあたり）が終了してしまい、デスクトップとして機能しなくなる現象が起きることがありました。OOMスコアの調整は、これを抑制するために、「 デスクトップを構成するプロセスよりも先に、アプリケーションを優先して停止する」ためのものです。
どのような調整なのかを理解するために、少しだけ詳しく見ていきましょう。
まずLinuxは古典的なUnixが採用する「厳格にメモリを確保する」方式の代わりに、物理メモリ（と設定されたswap）の上限を超えて『メモリを確保』できるように、つまりオーバーコミットを許容するようになっています（ちなみにこの挙動は変更できます） 。
これは「プログラムがメモリを確保する」ということと「実際にそのメモリを使い始める」ことのあいだにはギャップがあり、「 確保されたものの使われないメモリ」が相応に存在することを前提にしています。
この方式は効率よくメモリを使うことを可能にする一方、やっかいなトレードオフがあります。
オーバーコミットされている以上、アプリケーションがメモリを使い始めた時点、つまりは実際に「利用されるタイミング」で「利用できるメモリもswapもない」という事態が起きうるからです。この状態に突入した場合、Linuxカーネルはまず「なんとかして空いているメモリの断片をかき集める」処理を行います[1] 。しかしこの処理でも確保できない場合、「 OOM Killer」と呼ばれる処理を実施します。やることは単純で、「 過剰にメモリを消費していそうで、今のところ動いていなさそうなプロセス」を探して終了し、その分のメモリを明け渡すというものです。
カーネル側のOOM Killerによって停止されるプロセスはしばしば予想外なものになり、近年ではかなり「予想可能」になりつつありますが、これを調整するために、ユーティリティ的なプロセスとしてプロセスの優先順位を指定したり、といった『チューニング』も必要になります[2] 。
この『チューニング』に利用できるものがOOMスコアです。……しかし、この領域は実績や経験則の積み重ねがLinuxデスクトップ界隈（頻繁に元年が到来することでおなじみ）でも足りておらず、今回のチューニングはあくまで「第一歩」という形となっています。
[2] このチューニングのためのインターフェースが投入されたのは2018年のことで、それまでは「カーネルのOOM Killerが発動すると予想と異なるプロセスが終了されるかもしれないから、メモリ不足を察知して先に『メモリを消費しているが停止されても困らない』プロセスを探して終了する」というユーティリティのたぐいが複数存在していました。しかし「メモリ不足である」という判定がカーネル側と食い違っていたり、あるいは判定のタイミングと停止のズレから（メモリ不足な環境での動作はしばしば遅くなるので、「 停止しようとする処理」と「停止される」までの間には時間的なギャップが生まれます） 、「 この種のユーティリティがカーネル側のOOM Killerによって止められ、結果としてカーネルのOOM Killerが発動する」という事案が起きることもある、秘伝のタレとバッドノウハウと祈りが混在した魔界でした。
その他のニュース
[3] 各種「ファームウェア」は、しばしばOS側からデバイスに動的に読み込ませることが要求されます。今回検討されているlinux-firmwareはこうした「動的にロード」されるためのバイナリファイルを収録したものです。linux-firmwareのHWEは既存のカーネルのHWEとペアで利用されることが想定されるもので、「 新しいカーネル（に含まれる新しいドライバ－）ではより新しいファームウェアが要求されることがある」「 つまりカーネルだけHWEで新しくしても、セットになる新しいファームウェアが手に入らないことがある」「 結果として動作しなかったり、バグを誘発することがある」という問題への対応を意図したものです。
注目すべきセキュリティー的な視点： CISA Weekly Vulnerability Bulletinの終了US CISAがWeekly Vulnerability Bulletinの提供を終了する という方針が提示されました。
US CISAはアメリカの「サイバーセキュリティ・社会基盤安全保障庁」で、米国土安全保障省の外局として運用される、物理とサイバー空間の両面でインフラストラクチャーに対する脅威を削減する支援機関です。
Weekly Vulnerability Bulletinは週刊で提供される脆弱性情報で、要するに「CISAとして認識したその週に記録された新たな脆弱性の概要」をまとめたものです。実際の例としては9月14日週 のようなものです。購読しておくと毎週、「 前の週」に登場した脆弱性をリストにしたメールが届く、というものです（ただしHTMLのtableが大きすぎて開くとブラウザがしばらく固まることもしばしばある、という問題もありました） 。もちろんUbuntuの脆弱性も掲載されています。
この終了はBOD 26-04 という連邦政府、行政機関、各省庁機関への強制力のある運用指令に準拠するもので、CVSSによる深刻度だけでは優先順位を決められないこと、実際の悪用状況と資産の露出の組みあわせによって対応優先度が決まること、攻撃者によるAIの活用が、パッチ公開から悪用までの時間をさらに短縮され、そして「認識されているかどうか」と悪用の有無はあまり関連しないこと、といったことが整理されています。
これまでの典型的なセキュリティ対応パターンとしては、「 新しく発見された脆弱性の情報を元に緩和・解決のためのアクションを検討する」というものでした。しかしこれは、現代のような「AIが大量の脆弱性を発見し、脆弱性管理のための登録すら追いつかなくなる」「 あまりにも修正される脆弱性が多すぎる」という背景から、ベストプラクティスのたぐいが変質しつつあります。この廃止は象徴的なできごとの一つと言えるでしょう。
要するに「週刊ベースの新規脆弱性情報」というものの相対的な価値が失われた（リソースを費やす価値がなくなった）ためで、今後は「高リスクの脆弱性への対応を早め、低リスクの脆弱性への対応を後回しにする」（ すべてについて対応しようとするとリソースが足りない）ことを考慮しつつ、リスクベースアプローチへ切り替えるという「新しいお約束」に対応していくことが求められます。BOD 26-04ではそもそも「資産」と「資産の露出」を整理することが必要とされています。
