O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Monitoramento de tráfego eBPF

A ferramenta de tráfego de rede eBPF usa uma combinação de kernel e implementação de espaço do usuário para monitorar o uso da rede no dispositivo desde a última inicialização do dispositivo. Ele fornece funcionalidade adicional, como marcação de soquete, separando o tráfego de primeiro / segundo plano e firewall por UID para bloquear o acesso de aplicativos à rede, dependendo do estado do telefone. As estatísticas recolhidas a partir da ferramenta são armazenados em uma estrutura de dados do kernel chamada eBPF maps eo resultado é usado por serviços como NetworkStatsService para fornecer estatísticas de tráfego persistente desde a última inicialização.

Exemplos e fonte

As mudanças do espaço do usuário são principalmente nas system/netd e framework/base projectos. O desenvolvimento está sendo feito em AOSP, então o código AOSP estará sempre atualizado. A fonte está localizada principalmente no system/netd/server/TrafficController* , system/netd/bpfloader e system/netd/libbpf/ . Algumas mudanças estruturais necessárias estão em framework/base/ e system/core também.

Implementação

Começando com Android 9, os dispositivos Android rodando em kernel do 4.9 ou superior e enviado originalmente com o lançamento P deve usar o tráfego de rede com base em EBPF monitoramento contabilidade em vez de xt_qtaguid . A nova infraestrutura é mais flexível e mais fácil de manter e não requer nenhum código de kernel fora da árvore.

As principais diferenças de projeto entre o monitoramento de tráfego legado e eBPF são ilustradas na Figura 1.

Diferenças de projeto de monitoramento de tráfego legado e eBPF

Figura 1. Legacy (esquerdo) e EBPF monitoramento (direita) o tráfego diferenças de design

O novo trafficController projeto é baseado em per- cgroup filtro EBPF, bem como xt_bpf módulo netfilter dentro do kernel. Esses filtros eBPF são aplicados no pacote tx / rx quando eles passam pelo filtro. O cgroup filtro EBPF está localizado na camada de transporte e é responsável pela contagem do tráfego contra a UID para a direita dependendo do UID tomada, bem como configuração do espaço do usuário. O xt_bpf netfilter é enganchado no bw_raw_PREROUTING e bw_mangle_POSTROUTING cadeia e é responsável para a contagem de tráfego contra a interface correcta.

No momento da inicialização, o processo userspace trafficController cria a EBPF mapas utilizados para coleta de dados e os pinos todos os mapas como um arquivo virtual em sys/fs/bpf . Em seguida, o processo privilegiado bpfloader carrega o programa EBPF pré-compilados no kernel ea anexa à correcta cgroup . Há uma única raiz cgroup para todo o tráfego por isso todo o processo deve ser incluído nessa cgroup por padrão.

Em tempo de execução, o trafficController lata tag / socket um untag por escrito para o traffic_cookie_tag_map e traffic_uid_counterSet_map . O NetworkStatsService pode ler dados do tráfego estatísticas de traffic_tag_stats_map , traffic_uid_stats_map e traffic_iface_stats_map . Além função de cobrança do tráfego estatísticas, o trafficController e cgroup filtro EBPF também são responsáveis pelo bloqueio de tráfego de determinados UIDs, dependendo das configurações do telefone. O tráfego de rede baseada em UID recurso de bloqueio é um substituto do xt_owner módulo dentro do kernel eo modo de detalhe pode ser configurado por escrito para traffic_powersave_uid_map , traffic_standby_uid_map e traffic_dozable_uid_map .

A nova implementação segue o legado xt_qtaguid implementação do módulo de modo TrafficController e NetworkStatsService funcionará tanto com o legado ou nova implementação. Se o aplicativo usa APIs públicas, não deve sentir qualquer diferença se xt_qtaguid ferramentas ou EBPF são usados em segundo plano.

Se o kernel do dispositivo for baseado no kernel comum do Android 4.9 (SHA 39c856663dcc81739e52b02b77d6af259eb838f6 ou superior), nenhuma modificação nos HALs, drivers ou código do kernel será necessária para implementar a nova ferramenta eBPF.

Requisitos

  1. A configuração do kernel DEVE ter as seguintes configurações ativadas:

    1. CONFIG_CGROUP_BPF=y
    2. CONFIG_BPF=y
    3. CONFIG_BPF_SYSCALL=y
    4. CONFIG_NETFILTER_XT_MATCH_BPF=y
    5. CONFIG_INET_UDP_DIAG=y

    O VTS kernel do teste de configuração é útil ao verificar a configuração correta é ligado.

  2. O dispositivo MEM_LOCK rlimit deve ser definida para 8 MB ou mais.

Processo de suspensão de uso do xt_qtaguid legado

A nova ferramenta EBPF está substituindo o xt_qtaguid módulo eo xt_owner módulo é baseado em. Vamos começar a remover o xt_qtaguid módulo do kernel do Android e desativar suas configurações desnecessárias.

Na versão Android 9, o xt_qtaguid módulo é ligado em todos os dispositivos, mas todas as APIs públicas que ler diretamente o xt_qtaguid arquivo de módulo proc são movidos para a NetworkManagement Service. Dependendo da versão do kernel dispositivo e primeiro nível API, o NetworkManagement Serviço sabe se ferramentas EBPF está ligado e escolhe o módulo direito de obter para cada uso de estatísticas de rede aplicação. Aplicativos com SDK nível 28 e superior estão impedidos de acessar xt_qtaguid arquivos proc por sepolicy.

Na versão Android próxima após 9, acesso aplicativo para aqueles xt_qtaguid arquivos proc será completamente bloqueado vamos começar a remover o xt_qtaguid módulo dos novos núcleos comuns do Android. Depois que ele for removido, vamos atualizar a configuração base de Android para essa versão do kernel para ligar explicitamente a xt_qtaguid módulo off. O xt_qtaguid módulo será completamente obsoleto quando a exigência versão do kernel mínimo para uma versão Android é 4.9 ou superior.

Na versão do Android 9, apenas os dispositivos iniciados com a versão do Android 9 precisam ter o novo recurso eBPF. Para dispositivos enviados com um kernel que pode suportar ferramentas eBPF, recomendamos atualizá-lo para o novo recurso eBPF ao atualizar para o lançamento do Android 9. Não há teste CTS para impor essa atualização.

Validação

Você deve fazer regularmente os patches dos kernels comuns do Android e do Android AOSP master. Garantir a sua implementação passa os ensaios aplicáveis VTS e CTS, o netd_unit_test , eo libbpf_test .

Testando

net_tests do kernel para garantir que tenha os recursos necessários ligado e patches de kernel necessários portados. Os testes são integrados como parte dos testes VTS da versão Android 9. Existem alguns testes de unidade de system/netd/ ( netd_unit_test e libbpf_test ). Existem alguns testes em netd_integration_test para validar o comportamento global da nova ferramenta.

CTS e verificador CTS

Como os dois módulos de monitoramento de tráfego são compatíveis com a versão do Android 9, não há teste CTS para forçar a implementação do novo módulo em todos os dispositivos. Mas para dispositivos com a versão do kernel superior a 4.9 que vem originalmente com o lançamento do Android 9 (ou seja, o primeiro nível de API> = 28), existem testes CTS no GSI para validar se o novo módulo está configurado corretamente. Old CTS testes como TrafficStatsTest , NetworkUsageStatsTest e CtsNativeNetTestCases pode ser usado para verificar o comportamento para ser coerente com o módulo UID de idade.

Teste manual

Existem alguns testes de unidade de system/netd/ ( netd_unit_test , netd_integration_test e libbpf_test ). Há suporte para dumpsys para verificar manualmente o status. O comando dumpsys netd mostra o status básico do trafficController módulo e se EBPF está corretamente ligado. Se EBPF é ligado, o comando dumpsys netd trafficcontroller mostra o conteúdo detalhado de cada mapa EBPF, incluindo informações sobre o soquete marcado, estatísticas por tag, UID e iface e UID proprietário jogo.

Locais de teste

Os testes CTS estão localizados em:

VTS testes estão localizados no https://android.googlesource.com/kernel/tests/+/master/net/test/bpf_test.py .

Os testes de unidade estão localizados em: