BunのRust再実装: 「コードベースが基本的なMiri検査に失敗し、safe RustでUBを許容」

 (github.com/oven-sh)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • このイシューは現在 Open 状態で、議論は off topic としてロックされ collaborator に限定されており、関連修正として #30728 と #30876 が紐づけられている
  • 報告者は、PathString::init で作成した値が元の Box が drop された後でも slice() を呼び出せるため、Miri が dangling reference に基づく Undefined Behavior を報告すると示した
  • 再現コードは、Box::new(*b"Hello World") で作成したバッファを PathString::init(&*test) に渡した後、drop(test) の後で init.slice() を呼び出す形で、Miri は core::slice::from_raw_parts の地点でエラーを出した
  • robobun は問題が再現したことを確認し、PathString::init は safe 関数であるにもかかわらず slice lifetime を消去して dangling &[u8] を作れてしまうと整理した
  • 関連する #30728 は、PathString::init と dir_iterator::next() の並行した穴を unsafe fn に変更し、呼び出し箇所およそ70か所に backing allocation を明記した SAFETY コメントを追加する方向だという
  • 同じ修正には、3つのシグネチャで unsafe キーワードが必要であることを強制する compile_fail doctest と、resolver の readdir-error fd leak 修正も含まれていると説明されている
  • AwesomeQubic はさらに、PathString::init が provenance を消去しており、MIRIFLAGS=-Zmiri-strict-provenance でも失敗すると付け加えた
  • JavaDerg は、init が &[u8] の暗黙の lifetime を受け取り、unsafe な処理でそれを消去したうえで 'static のように見える Self を返すため、use-after-free と invalid aliasing を許してしまうと説明した
  • JavaDerg は、Rust の安全モデルの上では UB が予想外の場所で問題を引き起こし得るとして、unsafe の使用全般に対する見直しが必要であり、他言語のメモリ管理方式を Rust に 1:1 で翻訳するのは適切ではないと警告した
  • robobun は関連コミットとして PathString::init signature stays unsafe テストと dir_iterator: make next() unsafe; audit call sites を追加した
  • SimonReiff は、リポジトリの Rust ファイルでコメントを除いた unsafe の grep 結果が 13255 行だと示し、直ちに差し戻したうえで AI コード利用の方針と手順を議論すべきだと求めた
  • Jarred-Sumner は、Rust port は現在、元の Zig コードに可能な限り近い 1:1 mapping を出発点としており改善中だと述べ、Rust コードのバグや unsound behavior を引き続き新しいイシューとして報告してほしいと求めた

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsの意見

  • そもそも Bun に関心を持ったのは、Zig で書かれていたからで、Zig に惹かれたのは Andrew Kelley の意思決定とセンスを信頼していたからだ。
    その後 Bun にさらに興味を持った理由も、結局は自分が尊重できる選択だと感じたからで、Anthropic による買収後も慎重に楽観視しようとしていた。
    でも今回の動きは信頼しづらい意思決定に見える。Rust 自体が問題なのではなく、Anthropic が Bun をこんなふうに扱うなら、もはや信頼できる道具箱の一部として賭けるのは難しいという感覚だ。
    コードだけでなく、その背後にある考え方まで信頼できないといけないが、今は Anthropic 内部専用ツールのように見える。

    • Bun は本当に面白いプロジェクトだけれど、Issue に上がってくるセグメンテーションフォルトの数が、本番環境で真剣に使うにはあまりにも不安だった。
      今回の方向性はそれを直す一つの方法かもしれないので、見守る価値はある。
    • 理解はできるけれど、出発点はかなり違う。
      昔からの Deno ファンとしては、Bun は野心を少し抑えた Deno に見えていたし、Zig を学びたくなかったので、趣味としてでも Bun 自体に手を入れる可能性は低かった。
      ただ、この数年でランタイムにあまり縛られない形でかなり大きな TypeScript コードベースを維持しようとする中で、だんだん Bun に心が開いていった。特定の TypeScript ランタイムを要件にしたくはなかったが、Bun は Deno と同じように Postgres、SQLite、S3、WebSocket、ローカルシークレット保存、バンドリング、コンパイル、高速さといった理由を提供し続けていた。
      今では複数の API サーバーやフロントエンドのアプリサーバーを、bun build --compile --bytecode の単一実行ファイルにして、ほぼどこでも実行・配備している。
      ただ、こういう使い方が一般的だとは思わないし、今回のLLM ベースのポーティングが失敗したら、Bun に関する判断を全部後悔するにはちょうどいい位置にいる。
      それでも失敗しなければ面白い。LLM で何が可能かを示す事例になるし、今後 Bun が Rust で開発されるのは自分にとっては利点だ。
      逆に失敗しても情報として重要だ。Bun は主要な TS/JS ランタイムの一つで、Anthropic には莫大な資源と最新モデルへのアクセス、事実上無制限の予算がある。そういう彼らにできないなら、まだ本当に不可能だという意味に近い。
    • Bun が Deno より魅力的だった理由を知りたい。

  • Zig を安全でない Rust に移すつもりだったなら、なぜ翻訳ツールを作らなかったのか理解できない。
    言語構造を一対一でマッピングし、コードベースのパターンをハードコードすれば、決定的な変換が得られたはずだ。友人の言い方を借りれば、「zig translate-c を c2rust につなぐ」ようなこともできただろう。
    今の成果物は入力よりも信頼しづらい。入力はメモリ安全ではなかったが人間が直接書いたコードで、出力はメモリ安全でないうえにバイブコーディングされていて、人間がまともに目を通した形跡もない。
    こういう用途でエージェント型 AI を乱用する意味がわからない。

    • c2rust の出力を見たことがあるなら、そうは言いにくい。
      C の危険なポインタ意味論を Rust の unsafe 関数ライブラリで真似するような形になるので、結果はひどい。
      数年前に OpenJPEG のバグを見ていたとき、誰かが c2rust で変換してみたが、変換後の unsafe Rust も C コードと同じ箇所でセグメンテーションフォルトを起こしていた。
      互換性はあっても安全ではない。
      要するに、文字列操作を C や unsafe Rust でやるべきではないということだ。まったく向いていない道具だ。
    • 彼らは作った。非常に動的な翻訳ツールを。
    • 「zig translate-c を c2rust につなげばいい」というのは、思うほど簡単には動かない。
      こうしたツールはエラーが多く、コードを非常に冗長で推論しづらいものにしてしまう。
      小さなアプリには通用しても、全面的な書き換えには向いていない。
    • 自分も別スレッドでほぼ同じことを言ったが、ソフトウェアの書き方については少し違う見方をしている。
      Zig を Rust に翻訳するより、静的 Python で JPEG パーサーを書き、そのあと各言語に合ったイディオムな構造へ Zig と Rust に落とし込むほうが良いと思う。
      そのために、こうした目的向けの Python 方言パーサーを作っていて、ほとんどの Python コードとの互換性を保ちつつ、翻訳を容易にする Rust/Zig の機能の一部を取り込もうとしている。
      JPEG パーサーもサンプル資産に含まれている。
      https://github.com/py2many/static-python-skill
      https://github.com/py2many/spy-ast
    • コードベースを別の言語へ移植する正しい方法は、構文木をパースして、決定的かつ検証済みの変換を適用することだ。

  • この Issue は誤解を招く。
    問題は、miri が検出できる未定義動作が存在すること自体ではなく、安全なコードから未定義動作を引き起こせる API を公開していたことだ。miri も、それを証明するテストを書いてはじめて検出できる。
    安全でない言語からの初期ポートの間にこういうことが起きるのは、まったく不合理というわけではない。
    Bun チームもその後、unsafe コードを包む関数が正しいかどうかを点検しているようだ。
    ポート段階で一部の unsafe 関数を一時的に安全だと誤ってマークすること自体は大問題ではないが、その状態のまま main リポジトリにマージしたのは少し奇妙だ。
    本当の問題は、この状態のコードをリリースしたときだ。
    残念なのは、テストをすぐ miri で回すよう設定しなかったことだ。LLM は良いテストによく反応するからだ。
    この GitHub Issue のせいではなく、別のテスト [1] が miri で検出される未定義動作を実際に呼び出しているので、そう判断している。ただ、そのテスト対象コードはどこにも使われていないようで、現実的な影響は大きくなさそうだ。
    ポート初期なので後で直せるかもしれないし、実際には不要な unsafe コードをなくせるかもしれない。
    [1] https://github.com/oven-sh/bun/blob/4d443e54022ceeadc79adf54... - 最初の可変参照から派生したポインタが、同じオブジェクトに新しい可変参照を作ることで無効化されている。C 的には「可変参照」を「些細な変更が行われる restrict 参照」と考えればよい。
    正しくやるなら、すべてのポインタを同じ可変参照から派生させるべきだが、そうしていなかっただけだ。
    GitHub に押しかけて荒らせば、公の場で作業する可能性を減らすだけだ。そうしないでほしい。
    そして公開できる状態になるまで判断を保留するのがよい。途中の作業状態を評価するのは公平でもないし、あまり面白くもない。

    • プロジェクトが一度 1.0 に到達すると、多くの人は main ブランチが常に動くことを期待する。
      CI/CD は最終的に、すべてのコミットが動くことを前提にしているに近いからだ。
      全面書き換えのように動かない進行中コードはブランチでやるべきだ。
      そうすれば、セキュリティ修正のような対応が必要なときでも、動く main を維持できる。

  • この結果は、求められたやり方がほぼ逐語的なポーティングだったのだから驚くことではない。
    まずはもっと強い型システムを持つ言語へ Bun を移し、その型システムを足場にして後続の改善を行うほうがよい、と見ることもできるのではないか。
    最初の段階から完璧を求めるよりはましに思える。

    • 実際、彼らがやっているのはまさにそれだ。
      上がってくる Issue を処理していっている。
    • プロンプトに「未定義動作がないようにしろ」と追加すれば大丈夫だろう。
    • もう miri のようなツールで書き換えを追い込みつつ、Claude Code に自動で改善させられそうだ。
    • ほとんど逐語訳で、一部 unsafe な Rust コードから未定義動作が出るのは驚きではない。
      ただ、Rust コードの API が unsafe と明示されていないのに未定義動作を引き起こせる点は残念だ。
      こういう翻訳をするなら、保守的に進めて最初は全部または大半を unsafe としてマークしただろう。
      そのあと個々の部分の安全性を段階的に検証すればいい。

  • 正直、1 週間で完全に動くものにしたという話には少し驚いた。
    自分のサイドプロジェクト https://tsz.dev も似たような野心を持っているが、成功したとは言えない。
    ひたすらテストを追加して動作確認しており、TypeScript 自体のテストをすべて通したあとでも、予想どおりバグを見つけ続けている。
    tsc の挙動と一致させる基準は本当にとても高い。
    https://github.com/type-challenges/type-challenges
    LLM で多くのコードを書くこと自体には反対しないが、この速度でコードを吐き出せるようになった今、検証は 100 倍は堅牢であるべきだ。

    • 「実験」で、1 週間でレビューがほとんどされていない可能性が高い100 万行規模のコードをマージしたのは衝撃的だ。
      エージェントを使うこと自体には反対しないが、こういうことを急いで、コミュニティをいきなり驚かせるのは非常にアマチュアっぽく見える。
      やる気に満ちた新人エンジニアに期待するような振る舞いだ。
    • https://tsz.dev/sound-mode/
      これは素晴らしい。TypeScript にはこういうものがもっと必要だし、もっと知られて Microsoft が採用することすらあってほしい。
      ただ、名前を sound mode と呼ぶのは慎重になったほうがいい気がする。
      「数学的意味での soundness の証明ではなく、サードパーティの .d.ts ファイルを真にするわけでもない」という文には、まったく別の二つの話が混ざっている。
      第一に、健全性は数学的な概念だ。何かが健全なら本当に健全であり、細部を手で確認しなくてもコンパイラを信頼できるという意味だ。
      実装バグがあれば誤動作することはあるが、それは修正可能で、健全性とは仕様や型システム自体に理論上間違いがないことを指す。
      第二に、現実の言語では、人間が正しく使うと信じる未検査機能が必要なのはまったく問題なく、予想されることでもある。Haskell の unsafeCoerce や Java の sun.misc.unsafe のようなものだ。
      本当の問題は、そういう機能を使っていないのに型システムが壊れる場合だ。
    • 動くと呼ぶのは少し大げさだ。
      コードを数分見ただけだが、最適化を有効にした瞬間に大きく壊れそうに見える。
    • おそらく何か月も前からこれを計画して実験していたのだろう。
      大規模な既存テストスイートに加え、エージェントを並列化するツールや、事実上無制限のトークン予算もあったはずなので、そこまで落胆する必要はない。

  • 注意とメディアについての自分の考えを大きく変えた本がある [0]。
    本自体はそこまで素晴らしいわけではないが、ここに関係する点を突いている。
    大きく華やかな発表、たとえば「Bun が数週間でメモリ安全な Rust に書き換えられた」というメッセージの到達範囲と、訂正、たとえば古い記事の脚注や GitHub Issue の間には、ものすごい非対称性がある。
    この非対称性は マーケティングと PR 業界がよく理解していて、積極的に活用している。
    [0] https://en.wikipedia.org/wiki/Trust_Me,_I%27m_Lying

    • 今回の空気を見ると、コードに対するどんな批判でも見つけて最大限に増幅しようとしている人が多いように見える。
      現時点では、その大半はかなり浅い。
      大規模な LLM 補助ポートをマージしたのは確かにとても大胆な判断だが、実際の成果物について人々が指摘している内容の多くは、他の進行中のポートよりひどいとは感じない。
      見つかった Issue ごとに過剰に膨らまされている。
    • そもそも彼らが本当にメモリ安全だと主張したのか疑問だ。
      この話題のあらゆる議論には、バイブコーディングされたコードベースが監査されていない unsafe ブロックで爆発しそうだとか、Rust を理解していないような人たちが軽くレビューしただけだとかいうコメントが何十件も付いていた。
      ひどいと、どんなプログラミング言語でも理解すべきだという考え方そのものに腹を立てているように見えることすらある。
    • 「嘘は真実が靴を履く前に地球を半周する」という引用が言っている概念は、これのことかと思う。
    • マーケティングや PR だけでなく、主流メディアも、まずデタラメを流してあとで撤回しても持続効果があることを知っている。
      人は元の記事や見出しは覚えていても、訂正は見ていないことが多い。
    • むしろ逆方向の問題を言うのかと思った。
      ポートはまだ進行中で、大きく華やかな発表はなく、まだ完了もリリースもされていない。
      自分に見える派手な発表は、進行中コードへのヒットアンドラン的な嘲笑と、まるでチームが完成したとか完璧だと言ったかのように匂わせる試みのほうだ。
      書き換えは出発点にするためのコード翻訳だった。
      Bun チームは、コードが今やメモリ安全になったと大々的に発表したことはなく、出発点だとはっきり言ってきた。
      すぐに完璧で、元の Zig コードのあらゆるメモリ問題を解決しているはずだと期待するのは、Bun チームの実際の発表ではなく、想像上の発表と戦っているようなものだ。
      このメモリ問題が元のコードベースにも存在したのか、対応付けた人がいるのかも気になる。

  • この種のエラーは予想できた。
    安定性が必要な人向けに、安定版は Zig のまま残してあるし、最終的にはバグも修正されるだろう。

    • こうしたエラーは十分に避けられたはずだ。
      Rust エコシステムにはこうしたエラーを検出するよく知られたツールがあり、unsafe ブロックのミスによる未定義動作をすべて捕まえられなくても、実行するのが良い慣行だと考えられている。

  • いちばん気がかりなのはメタ会話だ。
    最初は、この GitHub Issue を話題外として閉じたメンテナーを批判的に見ていた。
    ところが GitHub の UI が、情報価値のまったくないメッセージ群をまとめて自動折りたたみしていて、それらはフォーラムやコミュニティ Discord から流入してきたように見えた。
    これは誰にとっても損だ。
    関連コミュニティの多くが懸念すべき重大な問題を見つけた人には、できるだけ広く知らせる十分な理由がある。
    これは最近の変更に対する実質的な要請であり、口調を問題にしたところで事実性が消えるわけではない。
    問題は、追加の注目が文字どおり議論を殺してしまうことだ。
    メンテナー側で、より感情的だったり AI 精神病に近い判断をする人への盾にもなりうる。
    批判を遮断し無視する包囲心理を持つプロジェクトは、非常に速く脱線しやすい。
    逆に、AI に対する不安や病理からメンテナーを守れないプロジェクトでは、メンテナーの燃え尽きは避けられない。

  • 今回の Bun 書き換えは、Mythos マーケティングのための潜在的イベントのように感じる。

    • 今のところ Bun チームや Anthropic の誰も、これを「より良いコンパイラ保証を持つ、よりメモリ安全な言語に変える」以上に盛って宣伝してはいない。
      現時点までの話題や広まりの大半は、AI に反対する人たちの否定的反応から来ている。
      自分としては、最近の Anthropic のいくつかの判断により Anthropic 自体への否定的認識が強まっていることも大きく絡んでいると思う。
    • ただの企業的ラグプルに見える。
      Anthropic の必要だけが唯一の優先事項で、他は気にしていないように感じる。
    • 無制限のトークンにどれだけ金を使ったのかもわからないほど書き換えを回す。
      「Claude Code が Bun チームによる 100 万行超の Zig の Rust への書き換えを可能にした」と大々的に騒いでブログ記事を書くと、VC がよだれを垂らす。
      基本的な検査で失敗する。
      Mythos にコードベースをずたずたに引き裂かせて、さらにどれだけ金を使うのかわからない。
      別のブログ記事を書く。
      詐欺師と単純な人たちが拍手しながら、「妄想的な反 AI 群衆」に対抗して擁護する。
      VC はさらに興奮する。
      これが金の稼ぎ方だ。
      そして今度はソフトウェアエンジニアも不要にすべきだ、という流れになる。

  • unsafe な言語のコードベースに、さらに別の unsafe な言語バインディングまで入っているのに、どうして最初から完璧に実装されているように見えるはずだと考えるのか、よくわからない。