Linux 7.4 に向けた「Y」の付箋と TDX のタイムアウト、ARM64 BE の撤去、Moose 0.6、BeamFS の RFC（2026/10/20 Linux・OSSトレンド）

はじめに

全部は直せないので、印を付け、線を引き、時間を区切る。今回の5本は、どれも直す前に扱い方を決めた話です。カーネルは bind/unbind を使った後のバグ報告に Y の付箋を貼り、Moose は外へ出すデータの範囲に線を引き、TDX では待たされる時間に区切りを付けます。

5本に共通点を見るのは、あくまで書き手の考察です。Linux 7.3 は10月18日（米国時間）に正式リリースされ、7.4 のマージウィンドウが開いたところです。経緯は10月19日の記事にあります。トピック1・3・5は、いずれも 7.4 に向けて送られた段階で、10月19日（UTC）の時点では torvalds/linux に入っていません。動画で一次情報と食い違った発言は、各節末の「動画の訂正」にまとめました。

1. Linux 7.4 の taint フラグ TAINT_FORCED_BIND — 文字は Y、ビット20

Greg Kroah-Hartman 氏が、新しい taint フラグ TAINT_FORCED_BIND を提案しました。最終版 v4 のカバーレターによれば、フラグの文字は、それまで使われていなかった “Y” です。パッチ本体では、tainted-kernels.rst の表に20番として “device was manually bound or unbound from a driver” が加わり、TAINT_FLAGS_COUNT が21になります。

7.4 への取り込み状況

Danilo Krummrich 氏が10月17日付で送った、driver core の7.4 向け pull requestに、このフラグを追加するコミットが含まれています。本文に “All commits have been in linux-next (no conflicts expected)” とあります。10月19日（UTC）の時点では、torvalds/linux の master の先頭は Linux 7.3 のままで、TAINT_FORCED_BIND は入っていません。7.4 で取り込まれる見込みです。

なぜ必要になったか

sysfs の bind と unbind のファイルは、カーネルを作り直さずに開発を回すための、昔からのデバッグ用の入口です。カバーレターによれば、この入口が syzbot のようなツールによる大規模なファジング “attack” にさらされ、どんなドライバでも、どんな種類のデバイスにでも無作為に結び付けようとする使い方をされました。その結果、“loads of unneeded errors and pointless kernel patches to be generated by unsuspecting new developers” が生まれたと書かれています。

syzbot は、syzkaller の文書によれば、見つけたバグをカーネルのメーリングリストへ自動で報告します。bind/unbind には正当な使い道もあり、Phoronix はハードウェアのリセットや “passing devices to a VM” を挙げています。

付箋の貼り方

カバーレターが挙げる狙いは、バグ報告のうち、見る価値のあるものを開発者が見分けやすくなることです。bind/unbind を使う正当な操作も、動作はそのまま続き、カーネルに印が付くだけです。taint は、動いているカーネルが標準と違う状態にあるという記録で、パニックではありません。

印を付ける位置には理由があります。カバーレターは、印が bind/unbind のコールバックの前に付くと明記しています。コールバックの中ではクラッシュや警告がよく起きるので、印が先にないと、何を試みていたかが oops のレポートに残らないためです。実装を見ると、印は対象のデバイスが見つかり、結合の条件を満たした直後の、コールバックの前で付きます。

カバーレターは、syzbot のようなツールは panic_on_taint を有効にして走らせるべきだとも書いています。panic_on_taint は、止めたい taint フラグを16進のビットマスクで指定する起動パラメータなので、Y という文字そのものは渡せません。bind/unbind のファイルを作らない設定（suppress_bind_attrs）のドライバは、そもそも書き込む先がないため、この印の対象になりません。

Y という文字について、カバーレターは、使われていなかった文字で、操作対象のデバイスを力任せに放り投げる “yeeting” として覚えられる、と説明しています。

動画の訂正です。

動画では「パッチはv3まで改訂が重ねられています」と紹介しましたが、7.4 向けの pull request に載ったのは最終版の v4 です（v1 から v4 まで4版。v4 は3パッチ構成）。根拠はv4 のスレッドで、pull request に載ったコミット3本とも一致します。
動画では Y を「yeetingから取った」と紹介しましたが、v4 のカバーレターの原文は、未使用だった文字 Y を yeeting と覚えられる、という覚え方の説明です。由来と言い切るのは言い過ぎでした。

2. GNOME 向け AI チャット Moose 0.6 — クラウドに接続できるようになった

Moose は、GTK4 と libadwaita で作られた GNOME 向けの AI チャットアプリです。READMEによれば、ローカルの AI モデル、または必要に応じてクラウドのプロバイダーと、ネイティブのアプリで会話できます。Rust 製で、ライセンスは GPL-3.0-or-later、Flathub で配布され、対応するアーキテクチャは aarch64 と x86_64 です。

0.6.0 と 0.6.1

0.6.0 のリリースは、GitHub 上の公開日時が10月7日（UTC）で、リリースノートは自分の API キーを使うクラウド接続を加えたと書いています。0.6.1 は10月17日（UTC）に公開され、Mistral AI と DeepSeek が加わりました。日本時間では、それぞれ10月8日と10月17日です。

キーの保管とプライバシー

0.6.0 のリリースノートは、クラウドの認証情報を保護して保存すると説明しています。AppStream の説明では “your desktop’s secret storage” です。実装は、Rust の oo7 クレートでデスクトップのキーリングを使うものです。

ローカル専用（Local Only）モードは、README によれば、リモートでの推論をブロックします。0.6.0 のリリースノートの言い方では、Moose が管理する Ollama だけを使う設定です。リモートのチャットでは、メッセージやファイルを共有する前に許可を求められます。メッセージとファイルの許可は別々で、リリースノートによれば、1つのチャットだけにも、同じプロバイダーのチャット全体にも設定でき、プライバシー設定からリセットできます。

外部の Ollama と保存まわり

外部の Ollama への接続は、0.6.0 から HTTPS が必須になりました。同じ端末の中の接続だけは HTTP も使えます。新しい Files 画面では、添付ファイルとライブラリの文書を閲覧、検索、絞り込みでき、プレビューや、関連するチャットを開き直すこともできます。リリースノートによれば、会話、下書き、文書ライブラリは端末内に保存されます。

README によれば、Flatpak 版はセットアップ手順に沿って Ollama を導入し、モデルのダウンロードまで進められます。

動画の訂正です。

動画では、API キーは「libsecret を通じて」GNOME のキーリングに保存されると紹介しましたが、公式の記述は “desktop keyring” で、libsecret の語はありません。実装は oo7 クレートです（README、資格情報のソース）。
動画では、会話の履歴を SQLite に保存して「全文検索もできる」と紹介しましたが、FTS5 の全文検索の対象は添付とライブラリの文書です。会話履歴の検索は部分一致です（マイグレーション）。

3. Linux 7.4 の ARM64 ビッグエンディアン対応の削除 — BROKEN の印から約1年

64ビット ARM のビッグエンディアン（BE）カーネルのサポートを削除するパッチが、7.4 に向けて送られています。

7.4 への取り込み状況

Catalin Marinas 氏が2026年9月23日に、arm64 ツリーの for-next/be-gone へ適用したと通知しました。適用されたのは v3 です。10月16日には、arm64 の 7.4 向け pull request が送られ、本文に “the removal of big-endian kernel support (already marked BROKEN for some time)” とあります。10月19日（UTC）の時点で torvalds/linux の master には入っておらず、7.4 で取り込まれる見込みです。

BROKEN から削除まで

CPU_BIG_ENDIAN を BROKEN に依存させるコミットは、MAINTAINERS の ARM64 PORT に Catalin Marinas 氏とともに載る Will Deacon 氏が書いたもので、本文に “as an initial deprecation step towards its removal” とあります。同じ本文は、BE の arm64 構成は “vanishingly rare” だと述べます。このコミットは 6.18 の開発サイクルで入り、6.18 の正式リリースは2025年11月30日でした。pull request まで約1年です。BROKEN の項目は、通常の設定メニューからは選べません。

Eric Biggers 氏はレビューの返信で、“It’s already been BROKEN (and thus is dead code) since v6.18.” と書き、さらに “Other code never actually worked correctly on big endian in the first place and no one ever cared.” と続けています。

規模と影響

v2 のカバーレターは14本のパッチで、diffstat は “41 files changed, 54 insertions(+), 539 deletions(-)” です。7.4 向けに送られた v3 は、Will Deacon 氏の13本に Catalin Marinas 氏が gve の Kconfig 依存を足した1本を加えた14コミットで、v3 のカバーレターの diffstat は “42 files changed, 53 insertions(+), 489 deletions(-)” です。

消えるものは、AES や GHASH の暗号アセンブリ、文字列処理の最適化ルーチン、-mbig-endian を指示するコンパイラのフラグなどです。KVM では、BE のハイパーバイザー側オブジェクトの生成と、nVHE の BE 用スピンロック定義が消えます。

7.3 以前のカーネルには影響しません。32ビット ARM の BE は今回の対象外で、Will Deacon 氏は v1 のスレッドで、arm32 側はもう1つ LTS を待つのがよいという考えを示しています。v1 と v3 のスレッドを見た範囲では、反対意見は見当たりませんでした。

動画の訂正です。

動画では「41ファイル、541行削除、54行追加」と紹介しましたが、v2 の diffstat では539行削除です。7.4 向けに送られたのは v3 で、v3 のカバーレターでは489行削除です。
動画では、KVM から消えるものを「ビッグエンディアンのゲスト向けコード」と紹介しましたが、正しくは、BE のハイパーバイザー側オブジェクト（ELF 再配置の生成）と、nVHE の BE 用スピンロック定義です（該当パッチ）。

4. BeamFS の RFC — 壊れた読み出しを返さないファイルシステム

BeamFS は、10月19日（Phoronix の記事日付）に、Linux カーネルのメーリングリストへ RFC として投稿された新しいファイルシステムです。Phoronix の記事は、カバーレターから次の文を引用しています。“beamfs is a block-device filesystem that corrects corrupted bytes in place, on a single device, with no second copy to repair from.”

誤り訂正の仕組み

カバーレターの引用によれば、各データブロックは lib/reed_solomon を土台にした、16本のインターリーブされた RS(255,239) の符号語で構成されます。ディレクトリブロック、inode、アロケーションビットマップ、スーパーブロックにも Reed-Solomon のパリティが付き、間接ブロックには専用のパリティ領域があります。

同じ引用によれば、既定のレイアウトでは4096バイトのうち288バイト（7%）がオーバーヘッドです。リポジトリの文書 capsule.mdによれば、このうちパリティは16バイト×16本の256バイトで、残りは検査値、自己識別、世代番号、予約領域です。

訂正できない読み出しは、間違ったバイト列を返さず -EIO で失敗します。Phoronix によれば、想定するのは、データを1台のストレージに置き、放射線を受けやすい環境で動くシステムです。同じく Phoronix によれば、前身の FTRFS は、人工衛星の搭載コンピューターや放射線治療室を念頭に置いて始まりました。

小ささという方針

開発者のリポジトリのKconfigには、DO-178C、ECSS-E-ST-40C、IEC 61508 の認証を設計上の制約とし、監査できるコードを5000行未満にする、と書かれています。脅威モデルの文書では、比較として ext4 を約10万行と見積もっています。これらは開発者自身の文書の記述で、RFC のカバーレターに載っているかは確認できていません。

FTRFS からの作り直し

前身の FTRFS は、2026年4月13日付の RFCでした。カバーレターの引用によれば、FTRFS の限界は設計（脅威モデル、訂正を置く場所、規模、カーネルとの統合）にあったため、BeamFS は独自のディスク上の形式を持つ新しいファイルシステムとして、新しいスレッドで投稿されています。

現在の版と既知の問題

READMEは、0.1.26 とその後の main に、データを失う、セキュリティを弱める、カーネルをクラッシュさせる既知の欠陥があると警告しています。10月9日のコードレビューで見つかったもので、それ以前のすべての版にもあるとしています。例として次のものがあります。

スパースファイルで、ページ先頭のブロックが穴のとき、読み出しがページ全体をゼロで返し、後の部分書き込みでそのゼロが保存されます。隣のブロックのデータが失われます
初期化されていないカーネルメモリの16バイトが、既定のレイアウトで各データブロックに書き込まれます
書き込みで set-user-ID と set-group-ID のビットが消えません

README は、失ってはいけないデータを置かないこと、自分で作っていないイメージをマウントしないこと、信頼できないユーザーが書き込めるシステムでマウントしないことを求めています。

動画の訂正です。

動画では「約288バイトが訂正用のパリティに使われる」と紹介しましたが、288バイト（約7%）はオーバーヘッド全体で、パリティはそのうち256バイトです（capsule.md）。
動画では、スパースファイルの不具合を「ページをまたいで書き込むと隣のブロックを壊す」と紹介しましたが、README の説明は、穴のブロックがゼロとして読まれ、そのゼロが後の書き込みで保存される、というものです。隣のデータが失われる結果は合っています。

5. Linux 7.4 の KVM/TDX — Instruction Timeout と Bus Lock VM Exit

TDX（Trust Domain Extensions）は、カーネルの文書によれば、ゲストのレジスタの状態を隔離し、メモリを暗号化して、機密ゲスト VM をホストと物理攻撃から守る仕組みです。今回の変更は、KVM が TDX ゲストに対して Instruction Timeout と Bus Lock VM Exit の2つを有効にできるようにするものです。なお、systemd-vmspawn の TDX 対応は9月3日の記事で扱いました。

7.4 への取り込み状況

シリーズは v4（9パッチ）で、Sean Christopherson 氏が kvm-x86 の vmx ブランチに適用しています。7.4 向けの pull request（Paolo Bonzini 氏宛て、10月16日）の件名は “KVM: x86: VMX+TDX changes for 7.4” で、同氏は受け取りを “Pulled all, thanks (for now to kvm/queue).” と返しています。Linus 宛ての pull request は確認できておらず、torvalds/linux の master にも入っていません。7.4 で取り込まれる見込みです。

Instruction Timeout

Instruction Timeout は、KVM では Notify VM Exit と呼ばれてきた機能です。pull request の文面は “now called Instruction Timeout in the SDM” と書きます。KVM の API 文書によれば、イベントウィンドウが開かないまま、指定した時間（notify window）が経過すると VM Exit します。目的は、悪意のある VM が CPU を固まらせ、ホストや他の VM が使えなくなる事態の緩和です。この機能は2022年にコミットされたもので、通常の VM 向けには前からありました。v4 のパッチによれば、IRET の実行中に起こることもあり、IRET が NMI のブロックを解除する場合は exit qualification のビット12が立ちます。

Bus Lock VM Exit

Bus Lock VM Exit は、v1 のカバーレターによれば、バスロックを発生させる命令の実行後に VM Exit します。“This VM exit is trap-like, meaning it does not prevent the bus lock from occurring but can detect that one has occurred.” という仕組みで、バスロックを止めるのではなく、起きたことを検出して通知します。通知先は QEMU などのユーザー空間です。

TDX でだけ有効になっていなかった

適用済みのコミットの説明によれば、ユーザー空間は TDX ゲストにこの機能を有効にしてもエラーを受け取りませんが、KVM が TDX モジュールの API を呼んで TD VMCS の対応する項目を設定しないため、実際には有効になっていませんでした。pull request の言い方は “KVM forgot to wire up the TDX Module knobs” です。Bus Lock 側は別のコミットで、TD VMCS の BUS_LOCK_DETECTION の設定と VM Exit のハンドラを加えます。

投稿者は Intel の Xiaoyao Li 氏で、v1（8月5日）から v4（8月19日）までの4版です。v4 のカバーレターによれば、最初の8パッチは stable カーネル向けです。そのため、ディストリビューションのカーネル更新でも届く見込みがあります。有効にするのはホスト側の VMM です。QEMU は Notify VM Exit を既定で有効にしますが、Bus Lock は bus-lock-ratelimit に0より大きい値を指定したときだけ有効になります。

動画の訂正です。

動画では、Instruction Timeout を「IRETという命令などの実行が一定の回数を超えると、CPUが強制的にゲストから制御を取り上げて、ホストに返す」と紹介し、一定回数で強制退場させる例えも添えましたが、回数ではなく時間の仕組みです。イベントウィンドウが開かないまま一定の時間が経過すると VM Exit します（api.rst の “a VM exit if no event window occurs in VM non-root mode for a specified of time (notify window)"、コミット 2f4073e08f4c）。動画タイトルの「時間を区切る」のほうが実態に合っています。
動画の終盤で「悪さを続けられる回数には上限を決めておく」「居座れる回数に上限を付けました」と紹介しましたが、Instruction Timeout は時間の上限です。Bus Lock VM Exit に上限はなく、バスロックの発生後に検出して通知する仕組みです（v1 のカバーレターの “does not prevent the bus lock from occurring but can detect that one has occurred”）。

まとめ

Y の付箋は、直さない代わりに見分けるための印でした。Moose は、クラウドへ送る範囲を自分で決められる作りです。ARM64 BE は、BROKEN を付けてから約1年で撤去に向かい、BeamFS は直せない破損を -EIO で知らせます。TDX は、中を見ない代わりに、固まる時間に区切りを付けます。この共通点は書き手の考察です。

確かめることを挙げます。

カーネルのバグ報告を読むなら、7.4 に取り込まれた後は taint の表示に Y があるかを確かめる。Y があれば、bind/unbind の操作があった報告です
Moose を試すなら、クラウドを使う前にプライバシー設定の共有範囲と、Local Only の設定を確かめる
ARM64 で BE カーネルを使っているなら、7.4 以降では BE のカーネルを作れなくなる見込みなので、7.3 以前に留まるか、移行を考える
BeamFS を試すなら、README の警告どおり、失ってもよいデータとイメージだけで試す
TDX のホストを運用する場合は、KVM と QEMU の更新で、Bus Lock の設定も含めて確かめる

参考リンク

（2026/10/20 Linux・OSSトレンド）