GKI 16-6.12 android-mainline errata

Esta página descreve problemas importantes e correções de bugs encontrados no android-mainline que podem ser significativos para os parceiros.

15 de novembro de 2024

• O Clang foi atualizado para 19.0.1 no android-mainline e no android16-6.12

  • Resumo: a nova versão do Clang apresenta um verificador de integridade de limites para matrizes, em que o tamanho da matriz é armazenado em uma variável separada vinculada à matriz usando o atributo __counted_by. Esse recurso pode causar um kernel panic se o tamanho da matriz não for atualizado corretamente. A mensagem de erro é semelhante a esta:

  UBSAN: array-index-out-of-bounds in common/net/wireless/nl80211.c
  index 0 is out of range for type 'struct ieee80211_channel *[] __counted_by(n_channels)' (aka 'struct ieee80211_channel *[]')
  

  • Detalhes: o higienizador de limites é essencial para proteger a integridade do kernel detectando acessos fora dos limites. Com o CONFIG_UBSAN_TRAP ativado, o higienizador de limites aciona um kernel panic em qualquer descoberta.

    • A versão anterior do higienizador de limites verificava apenas matrizes de tamanho fixo e não podia verificar matrizes alocadas dinamicamente. A nova versão usa o atributo __counted_by para determinar os limites da matriz em tempo de execução e detectar mais casos de acesso fora dos limites. No entanto, em alguns casos, a matriz é acessada antes que a variável de tamanho seja definida, o que aciona o higienizador de limites e causa um kernel panic. Para resolver esse problema, defina o tamanho da matriz imediatamente após alocar a memória subjacente, conforme ilustrado em aosp/3343204.

  • Sobre o CONFIG_UBSAN_SIGNED_WRAP: a nova versão do Clang higieniza o overflow e o underflow de números inteiros com sinal, apesar da flag do compilador -fwrapv. A flag -fwrapv foi criada para tratar números inteiros com sinal como complemento de dois e números inteiros sem sinal com comportamento de estouro definido.

    • Embora a higienização do estouro de números inteiros com sinal no kernel do Linux possa ajudar a identificar bugs, há casos em que o estouro é intencional, por exemplo, com atomic_long_t. Como resultado, o CONFIG_UBSAN_SIGNED_WRAP foi desativado para permitir que o UBSAN funcione apenas como um higienizador de limites.

  • Sobre o CONFIG_UBSAN_TRAP: o UBSAN é configurado para acionar um kernel panic quando detecta um problema para proteger a integridade do kernel. No entanto, desativamos esse comportamento de 23 de outubro a 12 de novembro. Fizemos isso para desbloquear a atualização do compilador enquanto corrigíamos problemas conhecidos do __counted_by.

1º de novembro de 2024

• Página de destino do Linux 6.12-rc4
  • Resumo: CONFIG_OF_DYNAMIC pode causar regressões graves em drivers com falhas.
  • Detalhes: ao mesclar o Linux 6.12-rc1 no android-mainline, notamos problemas com drivers fora da árvore que não carregavam. A mudança que expôs os bugs do driver foi identificada como commit 274aff8711b2 ("clk: Add KUnit tests for clks registered with struct clk_parent_data"), e nós a revertemos temporariamente em aosp/3287735. A mudança seleciona CONFIG_OF_OVERLAY, que seleciona CONFIG_OF_DYNAMIC. Com !OF_DYNAMIC, a contagem de referências em of_node_get() e of_node_put() é desativada porque eles são implementados como noops. Ativar OF_DYNAMIC de novo expõe problemas em drivers que implementam incorretamente a contagem de referências para struct device_node. Isso causa vários tipos de erros, como corrupção de memória, use-after-free e vazamentos de memória.
  • Todos os usos de APIs relacionadas à análise de OF precisam ser inspecionados. A lista a seguir é parcial, mas contém casos que temos observado:
    • Uso após o período sem custos financeiros (UAF, na sigla em inglês):
      • Reutilização do mesmo argumento device_node: essas funções chamam of_node_put() no nó fornecido, podendo precisar adicionar um of_node_get() antes de serem chamadas (por exemplo, ao chamar repetidamente com o mesmo nó como argumento):
        • of_find_compatible_node()
        • of_find_node_by_name()
        • of_find_node_by_path()
        • of_find_node_by_type()
        • of_get_next_cpu_node()
        • of_get_next_parent()
        • of_get_next_child()
        • of_get_next_available_child()
        • of_get_next_reserved_child()
        • of_find_node_with_property()
        • of_find_matching_node_and_match()
      • Uso de device_node após qualquer tipo de saída de determinados loops:
        • for_each_available_child_of_node_scoped()
        • for_each_available_child_of_node()
        • for_each_child_of_node_scoped()
        • for_each_child_of_node()
      • Manter ponteiros diretos para propriedades char * de device_node por perto, por exemplo, usando:
        • const char *foo = struct device_node::name
        • of_property_read_string()
        • of_property_read_string_array()
        • of_property_read_string_index()
        • of_get_property()
    • Vazamentos de memória:
      • Receber um device_node e esquecer de remover a referência dele (of_node_put()). Os nós retornados precisam ser liberados em algum momento:
        • of_find_compatible_node()
        • of_find_node_by_name()
        • of_find_node_by_path()
        • of_find_node_by_type()
        • of_find_node_by_phandle()
        • of_parse_phandle()
        • of_find_node_opts_by_path()
        • of_get_next_cpu_node()
        • of_get_compatible_child()
        • of_get_child_by_name()
        • of_get_parent()
        • of_get_next_parent()
        • of_get_next_child()
        • of_get_next_available_child()
        • of_get_next_reserved_child()
        • of_find_node_with_property()
        • of_find_matching_node_and_match()
    • Manter um device_node de uma iteração de loop. Se você estiver retornando ou interrompendo de dentro do seguinte, precisará descartar a referência restante em algum momento:
      • for_each_available_child_of_node()
      • for_each_child_of_node()
      • for_each_node_by_type()
      • for_each_compatible_node()
      • of_for_each_phandle()
  • A mudança mencionada anteriormente foi restaurada ao incluir o Linux 6.12-rc4 (consulte aosp/3315251) ativando o CONFIG_OF_DYNAMIC novamente e expondo drivers com falhas.