「メモリ安全な言語を使え」はそんなに単純な話ではない

Rustは本当に安全なのか？

C++は本当にそこまで安全ではないのか？

YouTubeで興味深いテーマの発表があったので持ってきました。
タイトルを訳すなら「メモリ安全な言語を使えという話は、そんなに単純な問題ではない」といったニュアンスに聞こえます。
発表者は一方に偏らない、比較的公正な立場から自分の考えを述べています。

• Rustはパニックによってメモリ安全でないコードの実行を防ぎますが、unsafe Rustはこの保護機能を回避できます。
• ただしunsafe Rustは明示的なオプトインが必要なため、安全でないC/C++よりも目立ちやすく、その部分を重点的にレビューできます。
• Rustクレートの約30%が安全でないコードを使用しており、組み込みシステムではその割合が2倍以上になります。
• Sanitizer（動的解析ツール）は、RustとC/C++の両方のコードでメモリエラーを検出できます。
• Rust開発者の70%が、C/C++ライブラリへのFFI（外部関数インターフェース）を通じて安全でないコードを呼び出しています。
• Rustプロジェクトで使われる多くの重要なライブラリも、C/C++で書かれています（SQLite、OPCUAライブラリ）。
• Sanitizersは、ソースコードがある場合、LLVM IR層でRustとC/C++の両方のコードを解析できます。
• Miriは、中間表現レベルでRustの未定義動作を検出するための補完ツールです。
• Miriの利点: 明確なエラーを提供し、あらゆる未定義動作を同時に確認できます。制限事項: C/C++コードは解釈できません。
• Rust標準ライブラリ関数の約20%が安全でないコードを使用しています。
• 重要インフラには、メモリ安全なコードだけでなく、財産被害や生命への脅威を防ぐための正しいコードが必要です。
• 安全なRustプログラムであっても、誤動作したり、サービス拒否攻撃に脆弱だったりする可能性があります。
• プロパティテストは、境界事例を見つけるためにランダム入力を生成することで役立ちますが、あり得ないエラーには苦戦します。
• Kaniは、数学を用いて制約条件内でプログラムの正しさを確認するモデルチェッカーです。
• Kaniの利点: 制約条件内のすべての入力を数学的に評価します。制限事項: ループを展開する必要があり、並行性やC/C++ FFIをサポートしません。
• Rustについての結論: Rustは安全ですが、思っているほど安全ではありません。
• Bjarne StroustrupはCとC++を区別し、C++はより安全なコードのために設計されたと述べています。
• C++ Core Guidelinesは、型安全、境界安全、寿命安全に関するプロファイルを提供し、Rustの保証に近づこうとしています。
• C++の最大の問題は、デフォルトで安全でないコードを書きやすすぎることです。開発者が努力していないわけではありません。