メモリ安全性絶対主義者

Piotr Sarnacki著 2026年7月28日 メモリ安全性絶対主義者 コメント: HN この投稿のタイトルを見たとき、おそらく多くの人の頭に最初に浮かんだのは「Rust開発者！」だったでしょう。この関連性は根拠がないわけではありません。Rust開発者はメモリ安全性に情熱を傾ける傾向があります。その一部は、古典的な言語戦争の姿勢、つまり「私の言語はあなたの言語より優れている、そしてその理由はこうだ」というものに起因していると確信しています。しかし、メモリ安全性に関心があると言う多くのRust開発者は、単にRustと競合する言語を批判するだけでなく、純粋にソフトウェアをより安全にすることに関心があることを願っています。 この記事は、驚くべきことに、Rust開発者に関するものではありません。 最近まで、メモリ安全性に関する議論は、少なくともC、C++、Zig、Rustのような非GCシステムプログラミング言語を考慮した場合、比較的単純な基盤を持っていました。Rustは、メモリ安全性の問題を引き起こす可能性のあるプログラムのコンパイルを（時には安全なプログラムでさえコンパイルできないというコストを払って）禁止することを目指しており、`unsafe`というエスケープハッチがあり、生ポインタの逆参照などが可能です。Cなどは、メモリ安全性の確保をプログラマーに委ねています。言語からのヘルプの量は異なります。例えば、C++にはRAIIやスマートポインタがあり、Zigには`defer`がありますが、ほとんどの場合、メモリへの不正アクセスを妨げるものはありません。 今日の状況は、C、C++、そして将来的にはZigのコードをメモリ安全にする新しい方法、Fil-Cの登場で少し異なります。Fil-CでコンパイルされたCおよびC++コードは、境界外アクセスやuse-after-freeのような不正なメモリアクセスが発生した場合にパニックを起こします。これは、GCと、ポインタがアクセス可能なメモリを追跡する方法であるInvisiCapsを組み合わせることで実現されます。Zigの作者は最近、Fil-Cに触発されたZigの新しいコンパイルモードを発表しました。 Fil-Cは非常に興味深いプロジェクトであり、それが成功し、少なくとも一部の人気のあるCおよびC++プロジェクトがFil-Cコンパイルリリースを提供するようになることを心から願っています。理想的な世界では、メモリ安全性に関心のあるRustプログラマーとC/C++/Zigプログラマーの両方が、メモリ安全性の脆弱性を最小限に抑えるための方法が増えたことを喜ぶでしょう。しかし、残念ながら、私たちは理想的な世界には住んでおらず、最近のRustに対する多くの批判が誠実でないという感覚を拭えません。 Fil-Cの作者のTwitterでの意見を読むと、彼がRustを嫌っていることは明白です。そして、彼はRustをメモリ安全ではない言語だと主張しており、`unsafe`を使用することでRustの保証の一部をバイパスできることを理由に挙げています。Zigの作者であるAndrew Kelleyも同様のスタンスを持っているようです。これは、filコンパイルモードのイシュータイトルの「Rustとは異なり、実際にメモリ安全なコンパイルモードを導入する」という言葉に示されています。つまり、Rustは安全ではなく、Fil-CまたはZigの「fil」コンパイルモードだけがメモリ安全性関連の脆弱性に対処できるということです。 RustとFil-Cに関連する議論では、「もしRustの人々が本当にメモリ安全性に関心があるなら、Fil-Cを推進しRustを捨てるべきだ。なぜならFil-Cの方が安全だからだ。そうでなければ、彼らは新しいピカピカの言語に関心があるだけで、メモリ安全性には関心がない」という主張をよく見かけます。これにはFil-Cの作者自身も含まれます。Andrew Kelleyについては確信がありませんが、私が言及したイシュータイトルは非常に近いように感じます。 これらの種類の議論は、私の意見では、現実を無視しており、しばしばRust開発者が非難されるような狂信的でカルト的な行動のように感じられます。 もしFil-Cが、全くトレードオフなしのドロップインリプレイスメントであったなら、私はその感情に部分的に同意したかもしれません。しかし、それはトレードオフを持っています。それは、Fil-CでコンパイルされていないプログラムとのABI互換性がなく、場合によっては数倍遅くなる可能性があり、GCを導入します。これらのうち、どれも一部のプログラムにとっては決定的な問題ではありません。あなたが毎日使用する多くのプログラムは、現在よりも数倍遅くても、あなたはそれに気づかないでしょう。また、多くのプログラムは動的にリンクしないため、ABI互換性は問題になりません。しかし、すべてのソフトウェアプログラムが単純なユーティリティであるわけではありません。GCとABI非互換性が問題となる人気のあるプロジェクトは数多くあり、それらがFil-Cのような技術を使い始めることは決してないでしょう、少なくとも現在の形ではありえません。 決定的に、Fil-Cを使用できないプログラムの種類は、しばしばRustに適しています。 しかし、Rustは安全ではないのですか？結局のところ、`unsafe`があります！もしあなたがそのように厳格になりたい、つまりメモリ安全性絶対主義者であれば、それはあなたにとっては真実かもしれません。私、そしておそらくほとんどの人は、それよりも現実的です。 Rustが実際にどれほど安全であるかについてのデータはあまりありませんが、私の知る限り、Rustソフトウェアで悪用可能なメモリ安全性脆弱性は多くありません。そして、Androidのような大規模プロジェクトでは、いくつかのデータがあります。 Androidプラットフォームには約500万行のRustコードがあり、潜在的なメモリ安全性脆弱性は1件見つかりました（リリース前に修正済み）。Rustの脆弱性密度は100万行あたり0.2件と推定されます。CおよびC++の過去のデータでは、100万行あたり約1,000件のメモリ安全性脆弱性の密度を示しています。私たちのRustコードは現在、桁違いに低い密度で推移しています。1000倍以上の削減です。これらの数値はプロジェクトによって異なると思いますが、実際にはRustがメモリ安全性問題の導入リスクを最小限に抑えていることは、今ではよく確立されていると思います。 もし、すべてのプログラムの100%で問題の99.9%を防ぐ技術か、90%のプログラムの100%の問題を防ぐ技術かを選択できるとしたら、どちらを選びますか？実際の数値は全く分かりませんが、意図は伝わるでしょう。 幸いなことに、一部の人々が主張するような、どちらか一方を選択する必要はありません。C/C++/Zigで書かれたプロジェクトで、トレードオフを受け入れられるものはFil-Cコンパイル済みバイナリとして利用可能になり、そうでないソフトウェアは、メモリ安全性脆弱性の導入リスクを完全にまたはほとんど除去する言語で書かれるべきだと私は思います。そして、GC言語（GoやFil-Cなど）も書けるプログラムであっても、Rustを使用することは全く問題ないと思います。 メモリ安全性絶対主義者は、それは許容できないと言うでしょう。ただし、彼らの一部は、Rustだけでなく、C、C++、Zigに対してもメモリ安全性絶対主義を適用しているようです。考えてみてください。 GC言語でも書けるプログラムは、しばしば`unsafe`を全く必要としません。そして、`unsafe`を必要とするプログラムは、GCを使用できなかったことが多いです。 私の経験では、問題を総狂信的なアプローチで解決しようとしない人々は、トレードオフを考慮する傾向があります。彼らの多くにとって、深刻なメモリ安全性問題に遭遇する非常に小さなリスクは、他の言語保証（データ競合防止など）や他の言語機能によって相殺されます。 さらに、100万行あたりの1000件のメモリ安全性関連の脆弱性を思い出してください。Fil-Cを使えば、それらはクラッシュになります。それでもセキュリティ脆弱性を導入するよりは良いですが、修正すべきクラッシュがかなり多いです。比較的まれな問題に怯えているのであれば、過去に攻撃者がプログラムをクラッシュさせることができたために発生したセキュリティ脆弱性があったことを述べるのは良いかもしれません。 もし、Rustの100万行あたり0.2件の脆弱性でさえ許容できないほどメモリ安全性に深く関心があるなら、Rust開発者と同じくらい、あるいはそれ以上に、YOLO C/C++や非fil Zigをコンパイルしている人々を批判してくれることを願っています。結局のところ、もしあなたが本当にメモリ安全性にそれほど強く関心があり、Rustでさえ十分に安全でないなら、人々がさらに安全性の低い代替手段を使用することを許容したくないでしょう？ この投稿が気に入ったら、Twitterでフォローすることを検討してください。 トップ