Google is committed to advancing racial equity for Black communities. See how.
本頁面由 Cloud Translation API 翻譯而成。
Switch to English

媒體框架強化

為了提高設備安全性,Android 7.0將整體mediaserver進程分為多個進程,其權限和功能僅限於每個進程所需的權限和功能。這些更改通過以下方法緩解了媒體框架安全漏洞:

  • 將視音頻管道組件拆分為特定於應用的沙盒過程。
  • 啟用可更新的媒體組件(提取器,編解碼器等)。

這些更改還通過顯著降低大多數與媒體相關的安全漏洞的嚴重性,從而確保最終用戶設備和數據的安全,從而提高了最終用戶的安全性。

OEM和SoC供應商需要更新其HAL和框架更改,以使其與新架構兼容。具體來說,由於供應商提供的Android代碼通常假定所有內容都在同一進程中運行,因此供應商必須更新其代碼,以傳遞對整個進程有意義的本機句柄( native_handle )。有關與媒體強化相關的更改的參考實現,請參閱frameworks/avframeworks/native

建築變化

Android的mediaserver版本使用具有很多權限(相機訪問,音頻訪問,視頻驅動程序訪問,文件訪問,網絡訪問等)的單個整體式mediaserver進程。 Android 7.0將mediaserver進程拆分為幾個新進程,每個進程都需要一組更小的權限:

媒體服務器強化

圖1.媒體服務器加固的體系結構更改

這種新的體系結構確保即使進程受到威脅,惡意代碼也無法訪問先前由mediaserver持有的全部權限。進程受SElinux和seccomp策略的限制。

注意:由於供應商的依賴性,某些編解碼器仍在mediaserver運行,因此為mediaserver授予了mediaserver更多權限。具體來說,Widevine Classic繼續在Android 7.0的mediaserver運行。

MediaServer更改

在Android 7.0中,存在用於驅動播放和記錄的mediaserver進程,例如,在組件和進程之間傳遞和同步緩衝區。進程通過標準的Binder機制進行通信。

在標準的本地文件回放會話中,應用程序將文件描述符(FD)傳遞給mediaserver (通常通過MediaPlayer Java API),以及mediaserver

  1. 將FD包裝到一個Binder DataSource對像中,該對像傳遞給提取器進程,該提取器進程使用FD使用Binder IPC從文件中讀取該FD。 (mediaextractor不會獲取FD,而是將Binder回調回mediaserver以獲取數據。)
  2. 檢查文件,為文件類型創建適當的提取器(例如MP3Extractor或MPEG4Extractor),然後將提取器的Binder接口返回給mediaserver進程。
  3. 進行Binder IPC調用,以提取文件以確定文件中的數據類型(例如MP3或H.264數據)。
  4. 調用mediacodec進程以創建所需類型的編解碼器;接收這些編解碼器的Binder接口。
  5. 反復對提取器進行Binder IPC調用以讀取編碼的樣本,使用Binder IPC將編碼的數據發送到mediacodec進程進行解碼,並接收解碼的數據。

在某些使用情況下,不涉及編解碼器(例如,將編碼數據直接發送到輸出設備的卸載回放),或者編解碼器可以直接呈現解碼數據,而不是返回解碼數據的緩衝區(視頻回放)。

MediaCodecService更改

編解碼器服務是編碼器和解碼器所在的位置。由於供應商的依賴性,並非所有編解碼器都存在於編解碼器過程中。在Android 7.0中:

  • 非安全解碼器和軟件編碼器存在於編解碼器過程中。
  • 安全解碼器和硬件編碼器位於mediaserver (不變)。

應用程序(或媒體服務器)調用編解碼器進程以創建所需類型的編解碼器,然後調用該編解碼器以傳遞編碼數據並檢索解碼的數據(用於解碼),或傳遞解碼數據並檢索編碼的數據(用於編碼) 。與編解碼器之間的數據傳輸已使用共享內存,因此該過程保持不變。

MediaDrmServer更改

播放受DRM保護的內容(例如Google Play電影中的電影)時,將使用DRM服務器。它以安全的方式處理解密的加密數據,因此可以訪問證書和密鑰存儲區以及其他敏感組件。由於供應商的依賴性,並非在所有情況下都使用DRM流程。

AudioServer的變化

AudioServer進程託管與音頻相關的組件,例如音頻輸入和輸出,確定音頻路由的policymanager服務以及FM廣播服務。有關音頻更改和實施指南的詳細信息,請參見實施音頻

CameraServer的更改

CameraServer控制攝像機,並在錄製視頻時用於從攝像機獲取視頻幀,然後將其傳遞給mediaserver進行進一步處理。有關更改的詳細信息以及有關CameraServer更改的實施指南,請參閱Camera Framework Hardening

ExtractorService更改

提取程序服務託管提取程序 ,這些組件解析媒體框架支持的各種文件格式。提取器服務是所有服務中特權最少的-它無法讀取FD,因此它會調用Binder接口( mediaserver for每次播放會話中提供給它)來訪問文件。

應用程序(或mediaserver )調用提取程序來獲取IMediaExtractor ,調用該IMediaExtractor來獲取文件中包含的軌道的IMediaSources ,然後調用IMediaSources從中讀取數據。

為了在進程之間傳輸數據,應用程序(或mediaserver )將數據作為Binder事務的一部分包含在Reply-Parcel中或使用共享內存:

  • 使用共享內存需要額外的Binder調用來釋放共享內存,但速度更快,並且對大型緩衝區使用的功耗更少。
  • 使用In-Parcel需要額外的複制,但速度更快,並且對小於64KB的緩衝區使用較少的電源。

實作

為了支持將MediaDrmMediaCrypto組件移至新的mediadrmserver進程中,供應商必須更改安全緩衝區的分配方法,以允許進程之間共享緩衝區。

在以前的Android版本中,安全緩衝區由OMX::allocateBuffer allocateBuffer在mediaserver OMX::allocateBuffer並在解密過程中以相同的過程使用,如下所示:

圖2. Android 6.0和Mediaserver中較低的緩衝區分配。

在Android 7.0中,緩衝區分配過程已更改為一種新機制,該機制可提供靈活性,同時最大程度地減少對現有實現的影響。在新的mediadrmserver進程中使用MediaDrmMediaCrypto堆棧時,緩衝區的分配方式有所不同,並且供應商必須更新安全緩衝區句柄,以便當MediaCodecMediaCrypto上調用解密操作時可以跨綁定程序傳輸MediaCrypto

圖3. Android 7.0及更高版本的mediaserver中的緩衝區分配。

使用本機句柄

OMX::allocateBuffer必須返回一個指向native_handle結構的指針,該結構包含文件描述符(FD)和其他整數數據。 native_handle具有使用native_handle所有優點,包括現有的對序列化/反序列化的活頁夾支持,同時為當前不使用FD的供應商提供了更大的靈活性。

使用native_handle_create()分配本機句柄。框架代碼擁有分配的native_handle結構的所有權,並負責在最初分配native_handle的過程和反序列化過程中釋放資源。該框架釋放與原生手柄native_handle_close()然後native_handle_delete()和串行/解串native_handle使用Parcel::writeNativeHandle()/readNativeHandle()

使用FD表示安全緩衝區的SoC供應商可以使用FD在native_handle填充FD。不使用native_buffer供應商可以使用native_buffer其他字段表示安全緩衝區。

設置解密位置

供應商必須更新的操作OEMCrypto解密方法native_handle執行必要使任何供應商特定的操作native_handle可用在新的處理空間(改變通常包括更新OEMCrypto庫)。

由於allocateBuffer是標準的OMX操作,因此Android 7.0包括一個新的OMX擴展名( OMX.google.android.index.allocateNativeHandle ),以查詢該支持;還有一個OMX_SetParameter調用,用於通知OMX實現應使用本機句柄。