Google is committed to advancing racial equity for Black communities. See how.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

Durcissement du cadre multimédia

Pour améliorer la sécurité des appareils, Android 7.0 divise le processus de mediaserver monolithique en plusieurs processus avec des autorisations et des capacités limitées à celles requises par chaque processus. Ces modifications atténuent les vulnérabilités de sécurité du cadre multimédia en:

  • Diviser les composants du pipeline AV en processus sandbox spécifiques à l'application.
  • Activation des composants multimédias actualisables (extracteurs, codecs, etc.).

Ces changements améliorent également la sécurité des utilisateurs finaux en réduisant considérablement la gravité de la plupart des vulnérabilités de sécurité liées aux médias, en protégeant les appareils et les données des utilisateurs finaux.

Les OEM et les fournisseurs de SoC doivent mettre à jour leurs modifications HAL et framework pour les rendre compatibles avec la nouvelle architecture. Plus précisément, étant donné que le code Android fourni par le fournisseur suppose souvent que tout s'exécute dans le même processus, les fournisseurs doivent mettre à jour leur code pour transmettre des native_handle natifs ( native_handle ) qui ont une signification à travers les processus. Pour une implémentation de référence des changements liés au durcissement des médias, reportez-vous aux frameworks/av et frameworks/native .

Changements architecturaux

Les versions précédentes d'Android utilisaient un processus de mediaserver monolithique mediaserver avec de nombreuses autorisations (accès caméra, accès audio, accès pilote vidéo, accès fichier, accès réseau, etc.). Android 7.0 divise le processus mediaserver en plusieurs nouveaux processus qui nécessitent chacun un ensemble d'autorisations beaucoup plus petit:

durcissement du serveur média

Figure 1. Modifications de l'architecture pour le durcissement du serveur média

Cette nouvelle architecture garantit que même si un processus est compromis, le code malveillant n'a pas accès à l'ensemble complet des autorisations précédemment détenues par mediaserver. Les processus sont limités par les politiques SElinux et seccomp.

Remarque: en raison des dépendances du fournisseur, certains codecs fonctionnent toujours dans le mediaserver et accordent par conséquent au mediaserver plus d'autorisations que nécessaire. Plus précisément, Widevine Classic continue de fonctionner dans le mediaserver pour Android 7.0.

Modifications de MediaServer

Dans Android 7.0, le processus mediaserver existe pour piloter la lecture et l'enregistrement, par exemple le passage et la synchronisation des tampons entre les composants et les processus. Les processus communiquent via le mécanisme standard de Binder.

Dans une session de lecture de fichier locale standard, l'application transmet un descripteur de fichier (FD) à mediaserver (généralement via l'API Java mediaserver ), et le mediaserver :

  1. Enveloppe le FD dans un objet Binder DataSource qui est transmis au processus d'extraction, qui l'utilise pour lire le fichier à l'aide de Binder IPC. (L'extracteur de média n'obtient pas le FD, mais effectue à la place des appels de Binder au mediaserver de mediaserver pour obtenir les données.)
  2. Examine le fichier, crée l'extracteur approprié pour le type de fichier (par exemple, MP3Extractor ou MPEG4Extractor) et renvoie une interface Binder pour l'extracteur au processus mediaserver .
  3. Fait appel à Binder IPC à l'extracteur pour déterminer le type de données dans le fichier (par exemple, des données MP3 ou H.264).
  4. Appelle le processus mediacodec pour créer des codecs du type requis; reçoit des interfaces Binder pour ces codecs.
  5. Fait des appels IPC Binder répétés à l'extracteur pour lire des échantillons codés, utilise l'IPC Binder pour envoyer des données codées au processus mediacodec pour décodage et reçoit des données décodées.

Dans certains cas d'utilisation, aucun codec n'est impliqué (comme une lecture déchargée où les données codées sont envoyées directement au périphérique de sortie), ou le codec peut rendre les données décodées directement au lieu de renvoyer un tampon de données décodées (lecture vidéo).

Modifications de MediaCodecService

Le service codec est l'endroit où vivent les encodeurs et les décodeurs. En raison des dépendances des fournisseurs, tous les codecs ne vivent pas encore dans le processus de codec. Sous Android 7.0:

  • Les décodeurs et encodeurs logiciels non sécurisés vivent dans le processus de codec.
  • Les décodeurs sécurisés et les encodeurs matériels vivent dans le mediaserver (inchangé).

Une application (ou mediaserver) appelle le processus de codec pour créer un codec du type requis, puis appelle ce codec pour passer des données codées et récupérer des données décodées (pour le décodage) ou pour transmettre des données décodées et récupérer des données codées (pour le codage) . Le transfert de données vers et depuis les codecs utilise déjà la mémoire partagée, de sorte que le processus reste inchangé.

Modifications de MediaDrmServer

Le serveur DRM est utilisé lors de la lecture de contenu protégé par DRM, comme des films dans Google Play Films. Il gère le déchiffrement des données cryptées de manière sécurisée et, en tant que tel, a accès au stockage de certificats et de clés et à d'autres composants sensibles. En raison des dépendances des fournisseurs, le processus DRM n'est pas encore utilisé dans tous les cas.

Modifications d'AudioServer

Le processus AudioServer héberge des composants audio tels que l'entrée et la sortie audio, le service policymanager qui détermine le routage audio et le service radio FM. Pour plus d'informations sur les modifications audio et les conseils de mise en œuvre, consultez Implémentation de l'audio .

Modifications de CameraServer

Le CameraServer contrôle la caméra et est utilisé lors de l'enregistrement vidéo pour obtenir des images vidéo de la caméra, puis les transmettre au mediaserver pour une manipulation ultérieure. Pour plus de détails sur les modifications et des conseils de mise en œuvre pour les modifications de CameraServer, reportez-vous à la section Renforcement du cadre de caméra .

Modifications d'ExtractorService

Le service d'extraction héberge les extracteurs , des composants qui analysent les différents formats de fichiers pris en charge par le framework multimédia. Le service d'extraction est le moins privilégié de tous les services - il ne peut pas lire les FD, donc à la place, il fait des appels à une interface Binder (fournie par le mediaserver for chaque session de lecture) pour accéder aux fichiers.

Une application (ou mediaserver ) appelle le processus d'extraction pour obtenir un IMediaExtractor , appelle cet IMediaExtractor pour obtenir IMediaSources pour la piste contenue dans le fichier, puis appelle IMediaSources pour en lire les données.

Pour transférer les données entre les processus, l'application (ou mediaserver ) inclut les données dans le colis de réponse dans le cadre de la transaction Binder ou utilise la mémoire partagée:

  • L'utilisation de la mémoire partagée nécessite un appel Binder supplémentaire pour libérer la mémoire partagée, mais est plus rapide et utilise moins d'énergie pour les grands tampons.
  • L'utilisation d'In -Parcel nécessite une copie supplémentaire, mais elle est plus rapide et utilise moins d'énergie pour les tampons inférieurs à 64 Ko.

la mise en oeuvre

Pour prendre en charge le déplacement des composants MediaDrm et MediaCrypto dans le nouveau processus mediadrmserver , les fournisseurs doivent modifier la méthode d'allocation des tampons sécurisés pour permettre le partage des tampons entre les processus.

Dans les versions précédentes d'Android, les tampons sécurisés sont alloués dans mediaserver par OMX::allocateBuffer mediaserver et utilisés lors du décryptage dans le même processus, comme indiqué ci-dessous:

Figure 2. Android 6.0 et allocation de tampon inférieure dans mediaserver.

Dans Android 7.0, le processus d'allocation de mémoire tampon est devenu un nouveau mécanisme qui offre de la flexibilité tout en minimisant l'impact sur les implémentations existantes. Avec les piles MediaDrm et MediaCrypto dans le nouveau processus mediadrmserver , les tampons sont alloués différemment et les fournisseurs doivent mettre à jour les descripteurs de tampon sécurisé afin qu'ils puissent être transportés à travers le classeur lorsque MediaCodec appelle une opération de déchiffrement sur MediaCrypto .

Figure 3. Allocation de tampon Android 7.0 et supérieur dans mediaserver.

Utilisation de poignées natives

L' OMX::allocateBuffer native_handle doit renvoyer un pointeur vers une structure native_handle , qui contient des descripteurs de fichier (FD) et des données entières supplémentaires. Un native_handle présente tous les avantages de l'utilisation des FD, y compris la prise en charge des classeurs existants pour la sérialisation / désérialisation, tout en permettant plus de flexibilité pour les fournisseurs qui n'utilisent actuellement pas de FD.

Utilisez native_handle_create() pour allouer le handle natif. Le code du framework prend possession de la structure native_handle allouée et est responsable de la libération des ressources à la fois dans le processus où le native_handle est alloué à l'origine et dans le processus où il est désérialisé. Le framework libère des native_handle_close() natifs avec native_handle_close() suivi de native_handle_delete() et sérialise / désérialise le native_handle utilisant Parcel::writeNativeHandle()/readNativeHandle() .

Les fournisseurs de SoC qui utilisent des FD pour représenter des tampons sécurisés peuvent remplir le FD dans le native_handle avec leur FD. Les fournisseurs qui n'utilisent pas de FD peuvent représenter des tampons sécurisés en utilisant des champs supplémentaires dans le native_buffer .

Définition de l'emplacement de déchiffrement

Les fournisseurs doivent mettre à jour la méthode de déchiffrement OEMCrypto qui fonctionne sur le native_handle pour effectuer toutes les opérations spécifiques au fournisseur nécessaires pour rendre le native_handle utilisable dans le nouvel espace de processus (les modifications incluent généralement des mises à jour des bibliothèques OEMCrypto).

Comme allocateBuffer est une opération OMX standard, Android 7.0 inclut une nouvelle extension OMX ( OMX.google.android.index.allocateNativeHandle ) pour interroger cette prise en charge et un appel OMX_SetParameter qui notifie l'implémentation OMX qu'il doit utiliser des OMX_SetParameter natifs.