プログラミング言語: Google が C++ メモリの安全性をどのように改善しているか

Google の Chrome チームは、Chrome の C++ コードベースにおけるメモリ関連のセキュリティ上の欠陥を軽減するためにヒープ スキャンを検討していますが、新しい Arm ハードウェアが使用されている場合を除いて、この技術はメモリに大きな負荷を与えます。

Googleは、Chromiumの既存のC++コードを単純にリッピングしてメモリ安全性の高いRustに置き換えることはできないが、ヒープに割り当てられたメモリをスキャンすることでC++のメモリ安全性を向上させる方法に取り組んでいる。 問題は、メモリに負荷がかかることと、現時点では実験段階にすぎないことです。

グーグルとマイクロソフトが大手 高速プログラミング言語 C++ のユーザーおよび貢献者、Chromium、Windows、Linux カーネル、Android などのプロジェクトで使用されます。 メモリの安全性が保証されているため、Rust の使用への関心が高まっています。

見る： 一生懸命働いていますか、それともほとんど働いていませんか？ 従業員は、同僚が在宅勤務中に生産性を発揮できると信じていない

しかし、Chrome の C++ から Rust のような言語に完全に切り替えることは、短期的には不可能です。

「メモリの安全性がより強力に保証されている C++ とは異なる言語に対する需要はありますが、Chromium などの大規模なコードベースでは当面は C++ が使用されるでしょう。」 Chrome セキュリティ チームの Anton Bikineev、Michael Lippautz、Hannes Payer が説明します.

この状況を踏まえ、Chrome エンジニアはメモリ関連のセキュリティを軽減するために C++ をより安全にする方法を見つけました。 すべてのソフトウェア セキュリティの 70% を占めるバッファ オーバーフローや Use-After Free (UAF) などの欠陥 欠陥。

C++ は、メモリが常にその構造の最新の情報を使用してアクセスされることを保証しません。 そのため、Google の Chrome チームは、「メモリ隔離」とヒープ スキャンを使用して、まだアクセス可能なメモリの再利用を停止することを検討してきました。

UAF は、ブラウザに影響を与える重大度の高い問題の大部分を占めています。 その好例が今週の Chrome 102 です。 1 つの重要な UAF を修正しました、 その間 重大度の高い欠陥 8 件中 6 件 UAFでした。

ヒープに割り当てられたメモリへの UAF アクセスは、メモリの使用時に発生する「ダングリング ポインタ」が原因で発生します。 アプリケーションによって基盤となるシステムに返されたが、ポインタが古いものを指している 物体。 ダングリング ポインタを介してアクセスすると UAF が発生しますが、大規模なコード ベースではこれを見つけるのが困難です。

UAF を検出するために、Google はすでに MiraclePtr のような C++ スマート ポインターを使用するこれは、コンパイラー、C++ サニタイザー、コード ファザー、およびオイルパンと呼ばれるガベージ コレクターでの静的分析だけでなく、パフォーマンスの低下も引き起こしました。 Rust の魅力は、コードがデバイス上で実行される前にコンパイラがポインタの間違いを検出し、パフォーマンスの低下を回避できることです。

実験段階を超えれば、ヒープ スキャンがこの武器に追加される可能性がありますが、採用は最新の Arm ハードウェアを使用するデバイスに依存します。

Google は隔離とヒープ スキャンの仕組みについて次のように説明しています:「隔離による一時的な安全性の確保の背後にある主な考え方」 ヒープ スキャンは、参照している (ぶら下がっている) ポインターがなくなったことが証明されるまで、メモリの再利用を避けるためのものです。 それ。 C++ ユーザー コードまたはそのセマンティクスの変更を避けるために、new および delete を提供するメモリ アロケーターがインターセプトされます。

Googleによると、削除を呼び出すと、メモリは実際には隔離され、アプリケーションによるその後の新しい呼び出しには再利用できなくなるという。 「ある時点でヒープ スキャンがトリガーされ、ガベージ コレクターのようにヒープ全体をスキャンして、隔離されたメモリ ブロックへの参照を見つけます。 通常のアプリケーション メモリからの受信参照がないブロックは、アロケータに転送され、その後の割り当てで再利用できます。

Google のヒープ スキャンは、StarScan (*Scan) と呼ばれる一連のアルゴリズムで構成されています。 しかし、*Scan の 1 つのバージョンでは、Speedometer2 ブラウザのパフォーマンス ベンチマーク テストで 8% のメモリ低下が発生しました。 *レンダリング プロセスでのスキャンにより、メモリ消費量が約 12% 低下したと Google は指摘しています。

次に Google は、パフォーマンスのオーバーヘッドを削減するために、ARM v8.5A の相対メモリ タグ付け拡張機能 (MTE) を介してハードウェア アシスト メモリ タグ付けを試みました。

見る： 開発者は燃え尽きてしまった。 これに対処するために彼らが取り組んでいることは次のとおりです

*Scan with MTE ベンチマーク結果は有望でした。 レンダラー プロセスの MTE 上で *Scan 実験を再実行した後、Speedometer2 ではメモリの回帰が約 2% でした。

「この実験はまた、MTE の上に *Scan を追加すると、測定可能なコストがかからないことも示しています」と彼らは書いています。

しかし現時点では、許容できないパフォーマンスの低下を引き起こさない方法でヒープ スキャンを実行することは、MTE がより広く採用される将来の課題として残ります。

「C++ を使用すると高パフォーマンスのアプリケーションを作成できますが、これにはセキュリティという代償が伴います。 ハードウェア メモリのタグ付けは、高いパフォーマンスを維持しながら、C++ のセキュリティ上の落とし穴を修正できる可能性があります」と Chrome セキュリティ チームは結論付けています。

「私たちは、将来的にハードウェア メモリのタグ付けがより広範に採用されることを期待しており、C++ の一時メモリの安全性を修正するために、ハードウェア メモリのタグ付けに加えて *Scan を使用することを提案します。 使用されている MTE ハードウェアと *Scan の実装は両方ともプロトタイプであり、パフォーマンスを最適化する余地がまだあると予想しています。」