Googleは、Android 13に続き、Android 14でハードウェアに近いレベルの開発
Google Online Security Blog: Bare-metal Rust in Android
どうしてRustなのか？
OSのカーネル外で実行されるようなモジュールは、歴史的な経緯もありC/
Cの言語特性をご存知であれば、実行速度や自由度の面で優れているが、メモリ管理はプログラマ任せなのは承知のとおりです。よって、ウェブアプリ開発で使われる言語と比較すると、気を使ってプログラムを書く必要があります。たとえば、いにしえのメモリセーフでないOSで、Cで書かれたアプリを実行して、メモリ操作を誤るとOSごと落とすことができました。
近年のOSでは、メモリ保護の一環として、こうした振る舞いをするアプリをトラップする仕組みを導入していますが、これらをすり抜けるケースもあって、脆弱性という形になって我々の目に現れています。
Androidの脆弱性は、メモリに関わるものが多くを占めており、2019年では223件が報告されています。
こうした状況を解決するための手段として、元凶のC/
Rustは、Android 12でサポートを開始して、Android 13からは、新しいコードの大半がRustで書かれています。この結果、メモリ操作に関わる脆弱性が2019年から2022年にかけて76％から35％までに減少しています。
Android 14の中のRust
Android 14では、pVMと呼ばれるブートローダの動きをするVMがRustで書き換えられています。ブートローダは、オープンソースのU-Bootが使われていましたが、セキュリティ的に要件の厳しい環境で使われることの考慮が少なく、多くの脆弱性が報告されています。
たとえば、NISTのデータベースには、バッファオーバーフローといった分かりやすい報告も見かけます。U-Bootの脆弱性は都度修正されていますが、もぐら叩きを続けるのではなく、Rustで書き換えることでメモリセーフになるという考えです。
これでは、U-Bootが諸悪の根源のようにも見えますが、これだけが理由ではなく、1999年の初版リリースから随分時間が経過しているのと、ベアメタル環境いるブートローダは、分かりやすい見直しの対象だったのかもしれません。
Android 14からは、新しいブートローターが搭載されてリリースされています。
ハードウェアによる保護も高度化
新しいコードはRustで書かれているとは言え、一夜にして、すべてのコードがRustへの書き換えが終わることはありません。たとえば、これに長けたエンジニアの育成も必要です。また、歴史のあるCと比べるとライブラリのサポートが低いこともあります。よってハードウェアによるメモリ保護の取り組みも進められています。
Android 14では、Arm v9に搭載されているMemory Tagging Extension (MTE) と呼ぶ、高度なメモリ保護機能が実装されています。Googleが公開していドキュメントでは、以下のように説明されています。
MTE は各メモリ割り当て / 割り当て解除に追加のメタデータをタグ付けし、タグをメモリ位置に割り当てます。タグは、そのメモリ位置を参照するポインタに関連付けることができます。CPU は実行時に、ポインタとメタデータのタグが読み込みと保存のそれぞれで一致するかどうかをチェックします。
筆者の理解では、確保されたメモリに誰のものかわかる名札をつけて、読み取り側の名札と一致するか確認し、一致しなければメモリアクセス違反などのエラーを返すような仕組みのようです。
MTEは、Pixel 8に搭載されているようで、
今週は、このあたりで、また来週。