Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Endurecimiento del marco de medios

Para mejorar la seguridad del dispositivo, Android 7.0 divide el proceso monolítico del mediaserver en múltiples procesos con permisos y capacidades restringidos solo a los requeridos por cada proceso. Estos cambios mitigan las vulnerabilidades de seguridad del marco de medios al:

  • Dividir los componentes de la canalización AV en procesos de espacio aislado específicos de la aplicación.
  • Habilitación de componentes de medios actualizables (extractores, códecs, etc.).

Estos cambios también mejoran la seguridad de los usuarios finales al reducir significativamente la gravedad de la mayoría de las vulnerabilidades de seguridad relacionadas con los medios, manteniendo seguros los dispositivos y los datos de los usuarios finales.

Los fabricantes de equipos originales y proveedores de SoC deben actualizar su HAL y los cambios en el marco para que sean compatibles con la nueva arquitectura. Específicamente, debido a que el código de Android proporcionado por el proveedor a menudo asume que todo se ejecuta en el mismo proceso, los proveedores deben actualizar su código para pasar identificadores nativos ( native_handle ) que tienen significado en todos los procesos. Para obtener una implementación de referencia de los cambios relacionados con el endurecimiento de medios, consulte frameworks/av y frameworks/native .

Cambios arquitectónicos

Las versiones anteriores de Android usaban un proceso de mediaserver único y monolítico con muchos permisos (acceso a la cámara, acceso al audio, acceso al controlador de video, acceso a archivos, acceso a la red, etc.). Android 7.0 divide el proceso del mediaserver en varios procesos nuevos, cada uno de los cuales requiere un conjunto de permisos mucho más pequeño:

endurecimiento del servidor

Figura 1. Cambios en la arquitectura para el endurecimiento del servidor de medios

Esta nueva arquitectura asegura que incluso si un proceso se ve comprometido, el código malicioso no tiene acceso al conjunto completo de permisos que anteriormente tenía mediaserver. Los procesos están restringidos por las políticas de SElinux y seccomp.

Nota: Debido a las dependencias de los proveedores, algunos códecs aún se ejecutan en mediaserver y, en consecuencia, otorgan a mediaserver más permisos de los necesarios. Específicamente, Widevine Classic continúa ejecutándose en el mediaserver de mediaserver para Android 7.0.

Cambios en MediaServer

En Android 7.0, el proceso del mediaserver existe para impulsar la reproducción y la grabación, por ejemplo, pasar y sincronizar búferes entre componentes y procesos. Los procesos se comunican a través del mecanismo Binder estándar.

En una sesión de reproducción de archivos local estándar, la aplicación pasa un descriptor de archivo (FD) a mediaserver (generalmente a través de MediaPlayer Java API), y mediaserver :

  1. Envuelve el FD en un objeto Binder DataSource que se pasa al proceso de extracción, que lo usa para leer del archivo usando Binder IPC. (El extractor de medios no obtiene el FD, sino que hace llamadas de Binder al mediaserver de mediaserver para obtener los datos).
  2. Examina el archivo, crea el extractor apropiado para el tipo de archivo (por ejemplo, MP3Extractor o MPEG4Extractor) y devuelve una interfaz de Binder para el extractor al proceso mediaserver .
  3. Hace llamadas Binder IPC al extractor para determinar el tipo de datos en el archivo (por ejemplo, datos MP3 o H.264).
  4. Llama al proceso mediacodec para crear códecs del tipo requerido; recibe interfaces de Binder para estos códecs.
  5. Realiza llamadas repetidas de Binder IPC al extractor para leer muestras codificadas, utiliza Binder IPC para enviar datos codificados al proceso de codificación de mediacodec para decodificación y recibe datos decodificados.

En algunos casos de uso, no hay códec involucrado (como una reproducción descargada donde los datos codificados se envían directamente al dispositivo de salida), o el códec puede representar los datos decodificados directamente en lugar de devolver un búfer de datos decodificados (reproducción de video).

Cambios en MediaCodecService

El servicio de códec es donde viven los codificadores y decodificadores. Debido a las dependencias de los proveedores, no todos los códecs se encuentran todavía en el proceso del códec. En Android 7.0:

  • Los decodificadores y codificadores de software no seguros viven en el proceso del códec.
  • Los decodificadores seguros y los codificadores de hardware viven en el mediaserver (sin cambios).

Una aplicación (o servidor de medios) llama al proceso del códec para crear un códec del tipo requerido, luego llama a ese códec para pasar datos codificados y recuperar datos descodificados (para descodificar) o para pasar datos descodificados y recuperar datos codificados (para codificar) . La transferencia de datos hacia y desde códecs ya usa memoria compartida, por lo que el proceso no se modifica.

Cambios en MediaDrmServer

El servidor DRM se utiliza al reproducir contenido protegido por DRM, como películas en Google Play Movies. Se encarga de descifrar los datos cifrados de forma segura y, como tal, tiene acceso al almacenamiento de certificados y claves y otros componentes sensibles. Debido a las dependencias de los proveedores, el proceso DRM aún no se utiliza en todos los casos.

Cambios de AudioServer

El proceso AudioServer aloja componentes relacionados con el audio, como la entrada y salida de audio, el servicio de administrador de políticas que determina el enrutamiento de audio y el servicio de radio FM. Para obtener detalles sobre los cambios de audio y la guía de implementación, consulte Implementación de audio .

Cambios en CameraServer

El CameraServer controla la cámara y se utiliza al grabar vídeo para obtener fotogramas de vídeo de la cámara y luego pasarlos a mediaserver para su posterior manipulación. Para obtener más información sobre los cambios y la guía de implementación para los cambios de CameraServer, consulte la Protección del marco de la cámara .

Cambios en ExtractorService

El servicio de extractor aloja los extractores , componentes que analizan los diversos formatos de archivo admitidos por el marco de medios. El servicio de extracción es el menos privilegiado de todos los servicios; no puede leer FD, por lo que realiza llamadas a una interfaz de Binder (proporcionada por el mediaserver for cada sesión de reproducción) para acceder a los archivos.

Una aplicación (o mediaserver ) realiza una llamada al proceso de extracción para obtener un IMediaExtractor , llama a ese IMediaExtractor para obtener IMediaSources para la pista contenida en el archivo y luego llama a IMediaSources para leer los datos de ellos.

Para transferir los datos entre procesos, la aplicación (o mediaserver ) incluye los datos en el paquete de respuesta como parte de la transacción de Binder o utiliza la memoria compartida:

  • El uso de memoria compartida requiere una llamada de Binder adicional para liberar la memoria compartida, pero es más rápido y usa menos energía para búferes grandes.
  • El uso de In-Parcel requiere un copiado adicional, pero es más rápido y consume menos energía para búferes de menos de 64 KB.

Implementación

Para admitir el movimiento de componentes MediaDrm y MediaCrypto al nuevo proceso mediadrmserver , los proveedores deben cambiar el método de asignación de búferes seguros para permitir que los búferes se compartan entre procesos.

En versiones anteriores de Android, OMX::allocateBuffer asigna búferes seguros en mediaserver y los usa durante el descifrado en el mismo proceso, como se muestra a continuación:

Figura 2. Android 6.0 y asignación de búfer inferior en mediaserver.

En Android 7.0, el proceso de asignación de búfer ha cambiado a un nuevo mecanismo que brinda flexibilidad y minimiza el impacto en las implementaciones existentes. Con las pilas MediaDrm y MediaCrypto en el nuevo proceso mediadrmserver , los búferes se asignan de manera diferente y los proveedores deben actualizar los identificadores de búfer seguros para que puedan transportarse a través del archivador cuando MediaCodec invoca una operación de descifrado en MediaCrypto .

Figura 3. Asignación de búfer de Android 7.0 y superior en mediaserver.

Usando identificadores nativos

OMX::allocateBuffer debe devolver un puntero a una estructura native_handle , que contiene descriptores de archivo (FD) y datos enteros adicionales. Un native_handle tiene todas las ventajas de usar FD, incluido el soporte de enlazador existente para serialización / deserialización, al tiempo que permite más flexibilidad para los proveedores que actualmente no usan FD.

Utilice native_handle_create() para asignar el identificador nativo. El código del marco toma posesión de la estructura native_handle asignada y es responsable de liberar recursos tanto en el proceso en el que se native_handle el native_handle originalmente como en el proceso en el que se deserializa. El marco libera identificadores nativos con native_handle_close() seguido de native_handle_delete() y serializa / deserializa native_handle usando Parcel::writeNativeHandle()/readNativeHandle() .

Los proveedores de SoC que utilizan FD para representar búferes seguros pueden completar el FD en native_handle con su FD. Los proveedores que no utilizan FD pueden representar búferes seguros utilizando campos adicionales en native_buffer .

Configuración de la ubicación de descifrado

Los proveedores deben actualizar el método de descifrado OEMCrypto que opera en native_handle para realizar cualquier operación específica del proveedor necesaria para que native_handle pueda usar en el nuevo espacio de proceso (los cambios generalmente incluyen actualizaciones a las bibliotecas OEMCrypto).

Como allocateBuffer es una operación estándar de OMX, Android 7.0 incluye una nueva extensión OMX ( OMX.google.android.index.allocateNativeHandle ) para consultar este soporte y una llamada OMX_SetParameter que notifica a la implementación OMX que debe usar identificadores nativos.