GrapheneOSのソーシャルネットワーク活動
- GrapheneOSはMastodonをベースにした分散ソーシャルネットワークの一部である。
- 公式プロジェクトアカウントとプロジェクトメンバー向けのGrapheneOSサーバーを運用している。
- サーバーには5人のアクティブユーザーがいる。
Pixel 8とPixel 8 Proのハードウェアメモリタグ付け対応
- Pixel 8とPixel 8 Proでのハードウェアメモリタグ付け対応を通じて、Android 14 QPR2のBluetooth LEで発生したメモリ破損バグを発見した。
- 現在このバグを調査し、修正するか、新たに導入された機能を一時的に無効化する暫定的な回避策を探している。
メモリタグ付けの無効化は暫定策として不適切
- 特定のBluetooth LEデバイスでのみ発生し、すべてのBluetoothデバイスで起きるわけではない。
- このプロセスに対するメモリタグ付けを無効化することは、短期的な解決策としても受け入れられない。
Android 14 QPR2のバグ修正パッチ開発
- Bluetooth LEに関連するuse-after-freeバグを発見し、パッチを開発した。
- GrapheneOSリリースに修正を含めることが優先事項であり、Androidのセキュリティバグとして報告する予定である。
- BLEオーディオの問題も解決される見込みである。
バグ修正の確認
- Samsung Galaxy Buds2 Proを使用しているユーザーがBluetooth LEモードで問題を再現し、修正が有効であることを確認した。
- この問題は標準のPixel OSにも影響する。
- GrapheneOSはhardened_mallocのメモリタグ付け対応を通じてこれを検出し、MTEクラッシュ通知とレポートを送れる機能を追加した。
セキュリティバグとして報告
- use-after-freeの問題はセキュリティバグとして報告された（Google社員向け b/328916844）。
- 初期の最小侵襲パッチが提供された。
- コードには大規模なリファクタリングが必要であり、生ポインタを使うべきではないが、迅速なパッチで新たなバグを持ち込まないようにしている。
BluetoothコードのRustへの移植
- Androidは多くのBluetoothコードをRustへ移植している。
- 残りのコードもRustへ移植するために、さらに多くのリソースを投入すべきである。
- HWASanとMTEビルドを、さまざまな実際の利用環境でテストする必要がある。
MTEの重要性
- Pixelは、OSで有効化しないことでメモリ/キャッシュ使用量を3.125%節約するために、MTEという重要なハードウェアセキュリティ機能を提供している。
- GrapheneOSは標準OSと既知の互換性があるユーザーインストール済みアプリに対して、デフォルトでMTEを有効にしている。
- ユーザーは設定から、すべてのユーザーインストール済みアプリに対してMTEを有効化できる。
GrapheneOSのMTE実装
- GrapheneOSは、標準のランダムタグと専用のfreeタグを使うhardened_mallocの一部として、より優れたMTE実装を提供している。
- Chromiumの統合を修正しており、PartitionAllocを改善する計画である。
GrapheneOSにおけるMTEの利用
- GrapheneOSは本番環境でMTEを利用する最初のプラットフォームである。
- Vanadiumブラウザは本番環境でMTEを利用する最初のブラウザである。
- スタックMTEを追加し、PartitionAllocを改善し、新しいカーネルslab MTEを作る計画である。
ユーザーからの感謝
- ユーザーたちはGrapheneOSのBluetooth自動無効化機能に感謝を示している。
GN⁺の見解
- GrapheneOSはAndroidベースのセキュリティ重視のOSであり、最新のPixel端末で見つかったメモリ破損バグを迅速に発見し対応する姿を示した。
- このような迅速な対応はオープンソースコミュニティの利点をよく示しており、ユーザーにより安全なモバイル環境を提供することに貢献している。
- メモリ安全性を強化するRust言語へのコード移植は、長期的なセキュリティ強化に向けた重要な段階である。
- ハードウェアベースのセキュリティ機能であるMTEを有効化することは、性能低下を最小限に抑えつつセキュリティを強化する効果的な方法である。
- この技術を導入する際には既存アプリケーションとの互換性を考慮する必要があり、セキュリティ強化のための適切なテストと保守が求められる。
1件のコメント
Hacker Newsのコメント
メモリタグ拡張機能はデフォルトでは有効になっていないが、開発者向けオプションから誰でも有効化できる。特定のアプリをテストしたいときに一度だけ有効にすることも、必要な間ずっと維持することもできる。
GrapheneOS のインストールが難しいのか、特別なケーブルが必要なのか、Android デバイスに詳しくないといけないのか、それとも手順に従うだけでよいのかについて、GrapheneOS ユーザーからの回答を期待している。
GrapheneOS を日常的に使うのが不便かどうか、スマートフォンが頻繁にクラッシュして数日間のデバッグが必要になるのか、銀行アプリが動作するのかについて、体験の共有を求めている。
Pixel チームが、メモリ／キャッシュ使用量を 3.125% 節約するために、重要なハードウェアセキュリティ機能（MTE）を OS で有効にしないという判断をどう正当化しているのか疑問に思っている。ヒープ MTE は非同期モードでは性能オーバーヘッドがほとんどなく、非対称モードでは SSP のような既存の徐々に効果が薄れている保護機能よりも低コストである。
MTE と CHERI のセキュリティ技術の比較についての質問。
GrapheneOS はセキュリティ面で他よりはるかに先を行っているため、Pixel ハードウェア以外を選ぶ理由が疑わしいと感じている。ただし、バッテリー交換可能な端末を強く望んでいる。
最新の Raspberry Pi のようなシングルボードコンピュータが Arm MTE を実装しているのかについての質問。
Solaris SPARC の 2015 年のハードウェアや、それ以前のメモリタグアーキテクチャのように、メモリ破損問題を解決できる主流ハードウェアを待っている。こうした問題の大半は、技量の不足した開発者によって引き起こされている。
2024 年には、seL4 の精神を受け継ぎつつ、より厳密に形式検証された OS、アプリケーション、ツールが必要である。現在のように、十分にテストされておらず過剰に設計されたコードベースのシステムを使うことは、ユーザーに危険をもたらし、多くのバグやマルウェア、ハッキングの攻撃対象領域を提供してしまう。
すっきりと統合されたユーザー体験（UX）と実用的な機能を提供できなければ、あらゆるエンジニアリングは無駄である。
Android は Bluetooth コードのかなりの部分を Rust に移植した。これは、さらに多くのコードを Rust に移植するために、より多くのリソースを投入すべきことを示す事例である。
C と C++ で長年作業してきたが Rust の経験はない人が、C から Rust への移植の過程でどれほど多くのリファクタリングが必要になるのか疑問に思っている。Google がこれにどう取り組んでいるのか、可能な限り直接「翻訳」しようとしているのか、それとも大規模な書き直し／リファクタリングの機会と見ているのかについての質問。
Android の Bluetooth スタックが、標準的な Linux ディストリビューションのデスクトップシステムで利用可能なのかどうか気になっている。