Microsoftが「Rust」言語を導入、安全性以外の理由あり（続報）：性能や安全性以外にも評価あり

Microsoft Security Response Center（MSRC）は、C／C++に代わるシステムプログラミング言語の最有力の選択肢として「Rust」を挙げ、その理由を解説した。合わせてMicrosoftのような大規模なコードベースを持つ企業にとっての課題も示した。

[＠IT]

　Microsoft Security Response Center（MSRC）は2019年7月22日（米国時間）、「C」や「C++」に代わるシステムプログラミング言語には何がふさわしいのか、最有力の選択肢として「Rust」を挙げ、理由を解説した（関連記事：Microsoft、安全で高効率のプログラミング言語として「Rust」を高く評価）。

なぜメモリ安全性と性能の両方が必要なのか

　MSRCによると、メモリ安全性を備え、Microsoft社内外で広く使われている言語は数多い。「C#」や「F#」のような.NETに対応した言語の他、「Swift」「Go」「Python」、Rustなどがある。

　だが、システムプログラミング言語はOSカーネルなど、他のソフトウェアの動作基盤となるシステムの作成に使うものだ。CやC++が提供するような速度と予測可能なパフォーマンスが必要だ。

　このため、ガベージコレクションによってメモリ安全性を確保している言語は、システムプログラミング言語として最適ではない。予測不能なパフォーマンスの一時的な低下や不要なオーバーヘッドの原因となることがあるからだ。

　とはいえ、CとC++はメモリ安全性を備えていない。

　MSRCは「パフォーマンスと制御」「安全性」「それ以外の側面」の3点を取り上げて、3種類の言語の優位性を比較した。

パフォーマンスと制御で優位にある言語は？

　C／C++は、システムプログラミング言語に不可欠なパフォーマンスと制御性を提供する。実はRustもこれらの言語と同様に、“ランタイム”が最小限であり、ランタイムを使わないことも可能だ。Rustの標準ライブラリは、C／C++と同様にRustをサポートするプラットフォームのlibcに依存する。標準ライブラリはオプションであるため、OSがないプラットフォームでもRustのコードは動作する。

　さらに、RustではC／C++と同様に、メモリを割り当てるタイミングと量をプログラマーがきめ細かく決定できる。このため、プログラマーはプログラムのパフォーマンスを的確に予測できる。

　実行速度、制御、予測可能性という観点から見たパフォーマンスでは、RustとC、C++は互角だと、MSRCは結論付けた。

メモリ安全性を保つことが可能な言語は？

　Rustは安全性の保証という点で、C／C++とは大きく異なる。Rustはプログラマーが意識的に破らない限り、完全なメモリ安全性を備えており、ランタイムオーバーヘッドを増やすことなく、メモリ破壊エラーを防ぐ仕組みを持っている。

　メモリの安全性は重大な問題になっている。Microsoftのセキュリティ問題のうち70％程度が、メモリの安全性に関わるものだからだ。つまり、MicrosoftのソフトウェアがRustで作成されていれば、全体の70％程度の問題を回避できていた可能性が高いということだ

　システムプログラミングでは、安全性を静的に保証できる処理以外を記述しなければならないことがある。だが、Rustであれば、このような処理をラップして安全に抽象化できる。

　Rust以前では、コードに対するコメントやプログラミング規約によって、メモリの安全性を保証していた場合があった。Rustではメモリ安全性が保証されていない処理は、明示的に「マーク」する必要がある。マークされていない場合はコンパイラが安全でないと検出する仕組みだ。

　このような仕組みはセキュリティ担当者にもメリットがある。メモリ安全性に関わる脆弱（ぜいじゃく）性を調査する際、対象領域を限定できるからだ。

それ以外の側面も評価を受けた

　RustがMSRC内で関心を呼んだ理由は以上の通りだ。だが、Microsoftの他部門はMSRCとはいくぶん異なる理由から、Rustを導入し始めた。