Segurança

Para evitar a execução de payloads arbitrários em uma pVM, o Framework de virtualização do Android (AVF) usa uma abordagem de segurança em camadas em que cada camada adiciona mais restrições. Confira a seguir uma lista de camadas de segurança do AVF:

  • O Android garante que apenas os apps com permissões de pVM possam criar ou inspecionar pVMs.

  • Bootloader: o bootloader garante que apenas imagens de pVM assinadas pelo Google ou fornecedores de dispositivos possam ser inicializadas e respeita o procedimento de inicialização verificada do Android. Essa arquitetura implica que os apps que executam pVMs não podem agrupar os próprios kernels.

  • A pVM oferece defesa detalhada, como com o SELinux, para payloads executados na pVM. A defesa detalhada não permite o mapeamento de dados como executáveis (neverallow execmem) e garante que W^X seja mantido para todos os tipos de arquivo.

Modelo de segurança

Confidencialidade, integridade e disponibilidade (tríade CIA) compõem um modelo criado para orientar as políticas de segurança da informação:

  • A confidencialidade é um conjunto de regras que limita o acesso às informações.
  • A integridade é a garantia de que as informações são confiáveis e precisas.
  • A disponibilidade é uma garantia de acesso confiável às informações por entidades autorizadas.

Confidencialidade e integridade

A confidencialidade vem das propriedades de isolamento de memória aplicadas pelo hipervisor pKVM. O pKVM rastreia a propriedade de memória de páginas de memória física individuais e todas as solicitações de proprietários para que as páginas sejam compartilhadas. O pKVM garante que apenas pVMs qualificados (host e convidados) tenham a página mapeada nas tabelas de página de estágio 2 controladas pelo hipervisor. Essa arquitetura mantém que o conteúdo da memória de uma pVM permanece privado, a menos que o proprietário o compartilhe explicitamente com outra pVM.

As restrições para manter a confidencialidade também se aplicam a todas as entidades no sistema que executam acessos de memória em nome de pVMs, ou seja, dispositivos com suporte a DMA e serviços executados em camadas com mais privilégios. Os fornecedores de sistema em chip (SoC) precisam atender a um novo conjunto de requisitos para oferecer suporte a pKVM. Caso contrário, não será possível garantir a confidencialidade.

A integridade se aplica aos dados na memória e à computação. As pVMs não podem:

  • Modificar a memória de outra pessoa sem consentimento.
  • Influenciar o estado da CPU um do outro.

Esses requisitos são aplicados pelo hipervisor. No entanto, problemas relacionados à integridade de dados também surgem com o armazenamento de dados virtuais quando outras soluções precisam ser aplicadas, como dm-verity ou AuthFS.

Esses princípios não são diferentes do isolamento de processo oferecido pelo Linux, em que o acesso às páginas de memória é controlado com as tabelas de páginas da fase 1 e as mudanças de contexto do kernel entre os processos. No entanto, a parte EL2 do pKVM, que impõe essas propriedades, tem três ordens de magnitude menos superfície de ataque em comparação com todo o kernel do Linux (aproximadamente 10 mil versus 20 milhões de linhas de código) e, portanto, oferece uma garantia maior para casos de uso que são muito sensíveis para depender do isolamento de processos.

Devido ao tamanho, o pKVM se presta à verificação formal. Estamos apoiando ativamente a pesquisa acadêmica, que tem como objetivo provar formalmente essas propriedades no binário pKVM real.

O restante desta página aborda as garantias de confidencialidade e integridade que cada componente de um pKVM oferece.

Hipervisor

O pKVM é um hipervisor baseado em KVM que isola pVMs e o Android em ambientes de execução não confiáveis. Essas propriedades são mantidas no caso de comprometendo qualquer pVM, incluindo o host. Hypervisors alternativos que atendem à AVF precisam fornecer propriedades semelhantes.

  • Uma pVM não pode acessar uma página que pertence a outra entidade, como uma pVM ou hipervisor, a menos que seja compartilhada explicitamente pelo proprietário da página. Essa regra inclui a pVM do host e se aplica a acessos de CPU e DMA.

  • Antes que uma página usada por uma pVM seja devolvida ao host, como quando a pVM é destruída, ela é apagada.

  • A memória de todas as pVMs e o firmware da pVM de uma inicialização do dispositivo são apagados antes que o carregador de inicialização do SO seja executado na inicialização subsequente do dispositivo.

  • Quando um depurador de hardware, como o SJTAG, é anexado, uma pVM não pode acessar as chaves criadas anteriormente.

  • O firmware da pVM não será inicializado se não for possível verificar a imagem inicial.

  • O firmware da pVM não será inicializado se a integridade do instance.img estiver comprometida.

  • A cadeia de certificados do DICE e os identificadores de dispositivo compostos (CDIs, na sigla em inglês) fornecidos a uma instância de pVM só podem ser derivados por essa instância específica.

SO convidado

O Microdroid é um exemplo de SO executado em uma pVM. O Microdroid consiste em um carregador de inicialização baseado em U-boot, GKI, um subconjunto do espaço do usuário do Android e um iniciador de payload. Essas propriedades são mantidas no caso de comprometimento em qualquer pVM, incluindo o host. Os SOs alternativos em execução em uma pVM devem fornecer propriedades semelhantes.

  • O Microdroid não será inicializado se boot.img, super.img, vbmeta.img ou vbmeta\_system.img não puderem ser verificados.

  • O Microdroid não será inicializado se a verificação do APK falhar.

  • A mesma instância do Microdroid não será inicializada, mesmo que o APK tenha sido atualizado.

  • O Microdroid não será inicializado se algum dos APEXes falhar na verificação.

  • O Microdroid não será inicializado (ou será inicializado com um estado inicial limpo) se o instance.img for modificado fora da pVM do convidado.

  • O Microdroid fornece atestado para a cadeia de inicialização.

  • Qualquer modificação (não assinada) nas imagens de disco compartilhadas com a pVM guest causa um erro de E/S no lado da pVM.

  • A cadeia de certificados e os CDIs do DICE fornecidos a uma instância de pVM só podem ser derivados por essa instância específica.

  • As gravações em um volume de armazenamento criptografado são confidenciais, mas não há proteção de reversão na granularidade de um bloco de criptografia. Além disso, outra adulteração externa arbitrária de um bloco de dados faz com que esse bloco apareça como lixo para o Microdroid, em vez de ser detectado explicitamente como um erro de E/S.

Android

Estas são propriedades mantidas pelo Android como o host, mas não são verdadeiras no caso de comprometimento do host:

  • Uma pVM de convidado não pode interagir diretamente com outras pVMs de convidado (por exemplo, para fazer uma conexão vsock).

  • Apenas o VirtualizationService no pVM host pode criar um canal de comunicação para um pVM.

  • Somente os apps assinados com a chave da plataforma podem solicitar permissão para criar, ter ou interagir com pVMs.

  • O identificador, chamado de identificador de contexto (CID, na sigla em inglês), usado na configuração de conexões vsock entre o host e a pVM não é reutilizado quando a pVM do host está em execução. Por exemplo, não é possível substituir uma pVM em execução por outra.

Disponibilidade

No contexto de pVMs, a disponibilidade se refere à alocação de recursos suficientes pelo host para que os convidados possam realizar as tarefas desejadas.

As responsabilidades do host incluem programar as CPUs virtuais da pVM. O KVM, diferente dos hipervisores convencionais de tipo 1 (como o Xen), toma a decisão de design explícita de delegar a programação de carga de trabalho ao kernel do host. Considerando o tamanho e a complexidade dos programadores atuais, essa decisão de design reduz significativamente o tamanho da base de computação confiável (TCB, na sigla em inglês) e permite que o host tome decisões de programação mais informadas para otimizar o desempenho. No entanto, um anfitrião mal-intencionado pode optar por nunca agendar um convidado.

Da mesma forma, o pKVM também delega o processamento de interrupções físicas ao kernel do host para reduzir a complexidade do hipervisor e deixar o host responsável pela programação. Esforços são feitos para garantir que o encaminhamento de interrupções de convidados resulte apenas em uma negação de serviço (interruptões muito poucas, muito frequentes ou mal direcionadas).

Por fim, o processo de monitor de máquina virtual (VMM) do host é responsável por alocar memória e fornecer dispositivos virtuais, como uma placa de rede. Um VMM malicioso pode reter recursos do convidado.

Embora o pKVM não forneça disponibilidade para convidados, o design protege a disponibilidade do host contra convidados maliciosos, porque o host pode sempre interromper ou encerrar um convidado e recuperar os recursos dele.

Inicialização segura

Os dados são vinculados a instâncias de uma pVM, e a inicialização segura garante que o acesso aos dados de uma instância possa ser controlado. A primeira inicialização de uma instância a provisiona gerando aleatoriamente um sal secreto para a pVM e extraindo detalhes, como chaves públicas de verificação e hashes, das imagens carregadas. Essas informações são usadas para verificar inicializações subsequentes da instância de pVM e garantir que os segredos da instância sejam liberados apenas para imagens que passam na verificação. Esse processo ocorre em todas as etapas de carregamento na pVM: firmware da pVM, pVM ABL, Microdroid e assim por diante.

O DICE fornece a cada fase de carregamento um par de chaves de atestado, cuja parte pública é certificada no certificado do DICE para essa fase. Esse par de chaves pode mudar entre inicializações. Portanto, um segredo de vedação também é derivado e é estável para a instância da VM em reinicializações e, como tal, é adequado para proteger o estado persistente. O segredo de vedação é muito valioso para a VM, portanto, não deve ser usado diretamente. Em vez disso, as chaves de vedação precisam ser derivadas do segredo de vedação, e o segredo de vedação precisa ser destruído o mais cedo possível.

Cada estágio transmite um objeto CBOR codificado de forma determinística para o próximo estágio. Esse objeto contém segredos e a cadeia de certificados do DICE, que contém informações de status acumuladas, como se o último estágio foi carregado com segurança.

Dispositivos desbloqueados

Quando um dispositivo é desbloqueado com fastboot oem unlock, os dados do usuário são excluídos permanentemente. Esse processo protege os dados do usuário contra acesso não autorizado. Os dados privados de uma pVM também são invalidados quando ocorre um desbloqueio do dispositivo.

Depois de desbloqueado, o proprietário do dispositivo pode refazer o flash de partições que geralmente são protegidas pela inicialização verificada, incluindo as partições que contêm a implementação do pKVM. Portanto, o pKVM em um dispositivo desbloqueado não será confiável para manter o modelo de segurança.

Partes remotas podem observar esse estado potencialmente não seguro inspecionando o estado de inicialização verificado do dispositivo em um certificado de atestado de chave.