Para melhorar a segurança do dispositivo, o Android 7.0 divide o processo monolítico mediaserver em vários processos com permissões e recursos restritos apenas aos exigidos por cada processo. Essas mudanças atenuam as vulnerabilidades de segurança da estrutura de mídia ao:
- Divisão de componentes de pipeline AV em processos em área restrita específicos do aplicativo.
- Habilitação de componentes de mídia atualizáveis (extratores, codecs, etc.).
Essas mudanças também melhoram a segurança dos usuários finais, reduzindo significativamente a gravidade da maioria das vulnerabilidades de segurança relacionadas à mídia, mantendo os dispositivos e dados dos usuários finais seguros.
OEMs e fornecedores de SoC precisam atualizar seu HAL e alterações de estrutura para torná-los compatíveis com a nova arquitetura. Especificamente, como o código Android fornecido pelo fornecedor geralmente pressupõe que tudo é executado no mesmo processo, os fornecedores devem atualizar seu código para transmitir identificadores nativos ( native_handle ) que tenham significado entre os processos. Para uma implementação de referência de mudanças relacionadas ao fortalecimento de mídia, consulte frameworks/av e frameworks/native .
Mudanças arquitetônicas
As versões anteriores do Android usavam um processo mediaserver único e monolítico com muitas permissões (acesso à câmera, acesso ao áudio, acesso ao driver de vídeo, acesso a arquivos, acesso à rede, etc.). O Android 7.0 divide o processo mediaserver em vários novos processos, cada um deles exigindo um conjunto muito menor de permissões:
Figura 1. Mudanças de arquitetura para proteção de servidor de mídia
Esta nova arquitetura garante que mesmo que um processo seja comprometido, o código malicioso não terá acesso ao conjunto completo de permissões anteriormente detidas pelo mediaserver . Os processos são restritos pelas políticas SElinux e seccomp.
Nota: Devido às dependências do fornecedor, alguns codecs ainda são executados no mediaserver e, consequentemente, concedem mediaserver mais permissões do que o necessário. Especificamente, o Widevine Classic continua sendo executado no mediaserver para Android 7.0.
Mudanças no MediaServer
No Android 7.0, o processo mediaserver existe para conduzir a reprodução e a gravação, por exemplo, passando e sincronizando buffers entre componentes e processos. Os processos se comunicam através do mecanismo Binder padrão.
Em uma sessão de reprodução de arquivo local padrão, o aplicativo passa um descritor de arquivo (FD) para mediaserver (geralmente por meio da API MediaPlayer Java) e para o mediaserver :
- Agrupa o FD em um objeto Binder DataSource que é passado para o processo extrator, que o utiliza para ler o arquivo usando o Binder IPC. (O mediaextractor não obtém o FD, mas em vez disso faz chamadas do Binder de volta ao
mediaserverpara obter os dados.) - Examina o arquivo, cria o extrator apropriado para o tipo de arquivo (por exemplo, MP3Extractor ou MPEG4Extractor) e retorna uma interface Binder para o extrator para o processo
mediaserver. - Faz chamadas IPC do Binder ao extrator para determinar o tipo de dados no arquivo (por exemplo, dados MP3 ou H.264).
- Chama o processo
mediacodecpara criar codecs do tipo necessário; recebe interfaces Binder para esses codecs. - Faz chamadas repetidas do Binder IPC para o extrator para ler amostras codificadas, usa o Binder IPC para enviar dados codificados ao processo
mediacodecpara decodificação e recebe dados decodificados.
Em alguns casos de uso, nenhum codec está envolvido (como uma reprodução descarregada em que os dados codificados são enviados diretamente para o dispositivo de saída) ou o codec pode renderizar os dados decodificados diretamente em vez de retornar um buffer de dados decodificados (reprodução de vídeo).
Mudanças no MediaCodecService
O serviço de codec é onde residem os codificadores e decodificadores. Devido às dependências do fornecedor, nem todos os codecs ainda estão no processo de codec. No Android 7.0:
- Decodificadores e codificadores de software não seguros residem no processo de codec.
- Decodificadores seguros e codificadores de hardware residem no
mediaserver(inalterados).
Um aplicativo (ou mediaserver ) chama o processo de codec para criar um codec do tipo necessário e, em seguida, chama esse codec para passar dados codificados e recuperar dados decodificados (para decodificação) ou para passar dados decodificados e recuperar dados codificados (para codificação) . A transferência de dados de e para codecs já usa memória compartilhada, portanto o processo permanece inalterado.
Mudanças no MediaDrmServer
O servidor DRM é usado ao reproduzir conteúdo protegido por DRM, como filmes no Google Play Filmes. Ele lida com a descriptografia dos dados criptografados de maneira segura e, como tal, tem acesso ao armazenamento de certificados e chaves e outros componentes confidenciais. Devido às dependências do fornecedor, o processo DRM ainda não é utilizado em todos os casos.
Mudanças no AudioServer
O processo AudioServer hospeda componentes relacionados ao áudio, como entrada e saída de áudio, o serviço policymanager que determina o roteamento de áudio e o serviço de rádio FM. Para obter detalhes sobre alterações de áudio e orientações de implementação, consulte Implementar áudio .
Mudanças no CameraServer
O CameraServer controla a câmera e é usado durante a gravação de vídeo para obter quadros de vídeo da câmera e depois passá-los para mediaserver para processamento posterior. Para obter detalhes sobre alterações e orientações de implementação para alterações no CameraServer, consulte Camera Framework Hardening .
Mudanças no ExtractorService
O serviço extrator hospeda os extratores , componentes que analisam os vários formatos de arquivo suportados pela estrutura de mídia. O serviço extrator é o menos privilegiado de todos os serviços – ele não pode ler FDs, então, em vez disso, faz chamadas para uma interface Binder (fornecida pelo mediaserver for cada sessão de reprodução) para acessar arquivos.
Um aplicativo (ou mediaserver ) faz uma chamada ao processo extrator para obter um IMediaExtractor , chama esse IMediaExtractor para obter IMediaSources para a faixa contida no arquivo e, em seguida, chama IMediaSources para ler os dados deles.
Para transferir os dados entre processos, o aplicativo (ou mediaserver ) inclui os dados no response-Parcel como parte da transação do Binder ou usa memória compartilhada:
- O uso da memória compartilhada requer uma chamada adicional do Binder para liberar a memória compartilhada, mas é mais rápido e usa menos energia para buffers grandes.
- Usar in-Parcel requer cópia extra, mas é mais rápido e usa menos energia para buffers menores que 64 KB.
Implementação
Para suportar a mudança dos componentes MediaDrm e MediaCrypto para o novo processo mediadrmserver , os fornecedores devem alterar o método de alocação de buffers seguros para permitir que os buffers sejam compartilhados entre processos.
Nas versões anteriores do Android, os buffers seguros são alocados no mediaserver por OMX::allocateBuffer e usados durante a descriptografia no mesmo processo, conforme mostrado abaixo:
Figura 2. Android 6.0 e menor alocação de buffer no mediaserver.
No Android 7.0, o processo de alocação de buffer mudou para um novo mecanismo que oferece flexibilidade e minimiza o impacto nas implementações existentes. Com as pilhas MediaDrm e MediaCrypto no novo processo mediadrmserver , os buffers são alocados de maneira diferente e os fornecedores devem atualizar os identificadores de buffer seguros para que possam ser transportados através do fichário quando MediaCodec invocar uma operação de descriptografia no MediaCrypto .
Figura 3. Android 7.0 e alocação de buffer superior no mediaserver.
Use identificadores nativos
O OMX::allocateBuffer deve retornar um ponteiro para uma estrutura native_handle , que contém descritores de arquivo (FDs) e dados inteiros adicionais. Um native_handle tem todas as vantagens de usar FDs, incluindo suporte de binder existente para serialização/desserialização, ao mesmo tempo que permite mais flexibilidade para fornecedores que não usam FDs atualmente.
Use native_handle_create() para alocar o identificador nativo. O código da estrutura assume a propriedade da estrutura native_handle alocada e é responsável por liberar recursos tanto no processo em que o native_handle está originalmente alocado quanto no processo em que ele é desserializado. A estrutura libera identificadores nativos com native_handle_close() seguido por native_handle_delete() e serializa/desserializa o native_handle usando Parcel::writeNativeHandle()/readNativeHandle() .
Os fornecedores de SoC que usam FDs para representar buffers seguros podem preencher o FD no native_handle com seu FD. Os fornecedores que não usam FDs podem representar buffers seguros usando campos adicionais no native_buffer .
Definir local de descriptografia
Os fornecedores devem atualizar o método de descriptografia OEMCrypto que opera no native_handle para executar quaisquer operações específicas do fornecedor necessárias para tornar o native_handle utilizável no novo espaço de processo (as alterações normalmente incluem atualizações nas bibliotecas OEMCrypto).
Como allocateBuffer é uma operação OMX padrão, o Android 7.0 inclui uma nova extensão OMX ( OMX.google.android.index.allocateNativeHandle ) para consultar esse suporte e uma chamada OMX_SetParameter que notifica a implementação do OMX de que ela deve usar identificadores nativos.