本頁說明記憶體安全錯誤和工具。
記憶體不安全
記憶體安全錯誤是在原生程式設計語言中處理記憶體時發生的錯誤，也是 Android 程式碼庫中最常見的問題。這類問題占高嚴重性安全漏洞的 60% 以上，且會導致數百萬使用者看到當機情形。
圖 1. 記憶體安全錯誤及其對品質、安全性和成本的負面影響。
記憶體安全錯誤會對品質和穩定性造成負面影響，且在使用者裝置上觀察到的當機事件中，這類錯誤占了相當大的比例。因此，記憶體安全錯誤密度越高，使用者體驗就越差。
以 C、C++ 和組合語言等記憶體不安全語言編寫的原生程式碼，占 Android 平台程式碼的 70% 以上，且約有 50% 的 Google Play 商店應用程式含有這類程式碼。
隨著程式碼日益複雜，如果放任不管，記憶體安全錯誤就會隨著時間增加。因此，為我們的生態系統提供可偵測及減輕這類錯誤的工具和技術，對我們的長期成功至關重要。
過去幾年來，我們與硬體合作夥伴密切合作，開發 Arm 記憶體標記等硬體技術，並在 Android 程式碼集導入 Rust。
這些技術將加速我們邁向記憶體安全之路，並協助更廣泛的軟體產業解決重要問題領域。
記憶體安全錯誤會對品質造成負面影響
潛在的記憶體安全錯誤可能會導致非決定性結果，具體取決於系統狀態。這種無法預測的行為會導致當機，並造成使用者困擾。
我們每天都會觀察到使用者裝置發生數百萬次原生當機事件，並透過導入 GWP-ASan，將大多數當機事件追溯至記憶體安全錯誤。
這項資料點可驗證記憶體安全錯誤的品質和密度之間的關聯性，與 Chrome 同事觀察到的情況一致 (請參閱 Chrome GWP-ASan 錯誤熱門清單)。
記憶體安全錯誤會對安全性造成負面影響
自 Android 首度發布以來，記憶體安全錯誤一直是 Android 安全漏洞的主要原因。
圖 2. 記憶體安全錯誤導致 Android 漏洞。
雖然得知這不只是 Android 的問題 (請參閱 Chrome 和 Microsoft 統計資料) 令人鼓舞，但我們仍需為使用者安全盡一份心力。
Google 的 Project Zero 團隊追蹤針對使用者發動的實際攻擊中，利用零時差漏洞進行的零時差攻擊。這些不是假設性錯誤，而是攻擊者主動用來攻擊使用者的漏洞。記憶體安全錯誤 (記憶體毀損和釋放後使用) 占絕大多數。
記憶體安全錯誤會增加成本
確保裝置安裝最新的安全性修正程式，可保障使用者安全，但會對我們的生態系統造成金錢損失。
低階供應商程式碼 (通常經過自訂修改) 中存在大量記憶體安全錯誤，大幅增加修正和測試成本。不過，在開發週期早期偵測到這些錯誤，可以降低這些成本。
研究顯示，及早偵測到錯誤最多可節省六倍的成本。不過，鑑於我們生態系統的複雜性，以及供應商維護的程式碼集平均數量和軟體複雜度不斷增加，節省的費用可能會更高。
記憶體安全
Android 12 以上版本包含系統性變更，可減少 Android 程式碼庫中的記憶體安全錯誤密度。我們將擴大 Android 記憶體安全工具的適用範圍，並推出新規定，鼓勵生態系統解決這類錯誤。長期而言，這些措施應能為使用者帶來更高品質、更安全的體驗，並降低供應商的成本。
記憶體安全很可能在未來幾年成為品質和安全性的差異化因素，而 Android 打算引領這股趨勢。
支援記憶體安全性的需求
Android 相容性定義說明文件 (CDD) 強烈建議在開發期間使用記憶體安全工具。
我們正與生態系統密切合作，提高記憶體安全工具的使用率，並將這些工具整合到持續整合和測試程序中。
我們希望確保每部裝置都能通過完整的 Compatibility Test Suite (CTS) 執行作業，並使用記憶體安全工具，證明沒有發現這類錯誤。舉例來說，Arm v9 平台必須提供啟用記憶體標記的 CTS 執行作業，而 Arm v8 平台則必須提供使用 HWASAN 和 KASAN 的 CTS 執行作業。
Rust 做為平台程式碼的新程式設計語言
Android 12 將 Rust 導入為平台語言。Rust 提供的記憶體和執行緒安全防護功能，效能與 C/C++ 類似。我們預期 Rust 會成為大多數新原生專案的首選。不過，目前 Android 平台程式碼有超過 70% 屬於記憶體不安全程式碼，因此全部以 Rust 重新編寫並不可行。未來 Rust 將與記憶體安全工具相輔相成。
記憶體安全工具
Android 支援多種工具，可協助偵測記憶體安全錯誤。下圖顯示可用的 Android 記憶體安全工具分類。
圖 3. Android 記憶體安全工具現況。
我們的工具涵蓋各種部署情境和目標。本節的說明文件會介紹各項工具，並提供在產品中使用這些工具的參考資料。