Engenheiros do Google que contribuem para o kernel Linux anunciaram que descobriram centenas de "Condições de corrida" no kernel usando KCSAN. A empresa vem trabalhando há muito tempo no AddressSanitizer para encontrar erros relacionados à corrupção de memória ou UndefinedBehaviorSanitizer para comportamento indefinido no código.
Desta vez, O Google oferece um novo detector de “Condições de corrida” para o kernel Linux chamado KCSAN (Sanitizer de simultaneidade de kernel). Essas vulnerabilidades críticas não são novas. Na verdade o Condições de corrida ocorrem quando dois ou mais threads no mesmo processo acessam o mesmo local de memória simultaneamente, onde pelo menos um dos acessos é para gravar e quando os encadeamentos não usam nenhum bloqueio exclusivo para controlar seu acesso a essa memória.
Quando essas condições são atendidas, a ordem de acesso não é determinística e o cálculo pode dar resultados diferentes de uma execução para outra, dependendo dessa ordem.
Condições de corrida são cada vez mais vistas como erros de acesso simultâneos e são difíceis de duplicar e diagnosticar em programas paralelos. O kernel Linux é um sistema de software em grande escala, no qual o paralelismo intensivo de thread e a intercalação de thread não determinística estão mais sujeitos às condições competitivas.
Algumas situações competitivas podem ser benignas, mas muitas delas identificadas até o momento são consideradas erros.
O kernel do Linux oferece vários mecanismos para evitar e gerenciar esses tipos de condições Uma vez que existem ferramentas como Thread Analyzer ou KTSAN (Kernel Thread Sanitizer) para detectar erros críticos de execução no kernel do Linux.
No entanto, o Google, que também contribui para o kernel Linux, recentemente propôs KCSAN, um novo detector de condições de corrida para o kernel, semelhante ao KTSAN.
De acordo com o Google, o KCSAN se concentra em descobrir situações competitivas no código do kernel. Este detector dinâmico de acertos críticos é uma alternativa ao Kernel Thread Sanitizer (KTSAN).
De acordo com a explicação do Google, KCSAN é baseado em pontos de monitoramento de amostragem, ao contrário do detector KTSAN, que é um detector de corrida crítica antes do evento. As principais prioridades no projeto KCSAN são a falta de falsos positivos, escalabilidade e simplicidade.
KCSAN usa ferramentas de compilação para acessar a memória. KCSAN é compatível com os compiladores GCC e Clang. Com o GCC, ele requer a versão 7.3.0 ou posterior e com o Clang, ele requer a versão 7.0.0 ou posterior.
Na página GitHub do projetoMarco Elver, do Google, escreveu que, usando o KCSAN em testes no mês passado, eles encontraram em apenas dois dias mais de 300 situações de competição principais. O KCSAN oferece várias opções de configuração para personalizar seu comportamento.
“Temos usado o KCSAN por meio do Syzkaller por várias semanas e encontramos muitos bugs. Inicialmente, em setembro de 2019, identificamos mais de 300 situações de competição exclusivas em apenas dois dias ”, escreveu ele.
O Google disse que a abordagem geral é baseada no DataCollider, outro detector dinâmico de situações competitivas nos módulos do kernel. Mas, ao contrário do DataCollider, o KCSAN não usa pontos de monitoramento de hardware, em vez disso, depende de ferramentas de compilação.
Os pontos de monitoramento são implementados usando uma codificação eficiente que armazena o tipo, tamanho e endereço de acesso em um arquivo longo. Os benefícios de usar pontos de monitoramento flexíveis são portabilidade e maior flexibilidade para limitar o acesso que um ponto de monitoramento pode ativar.
Aqui estão alguns dos pontos-chave que a KCSAN fez para o Google:
- Alto rendimento: O tempo de execução do KCSAN é mínimo e não requer bloqueio de estado compartilhado para cada acesso. O resultado é um desempenho muito melhor do que o KTSAN.
- Sem memória adicional: de acordo com o Google, nenhum cache é necessário. A implementação atual usa um pequeno número de comprimentos para codificar as informações do ponto de monitoramento, o que é insignificante.
- Comando de memória: KCSAN não conhece as regras de controle do modelo de memória do kernel do Linux (LKMM). Isso pode resultar em corridas críticas perdidas (falsos negativos) em comparação com um detector de corrida pré-evento como o KTSAN
- Precisão: De acordo com o Google, o KCSAN é impreciso porque usa uma estratégia de amostragem;
- Requer anotação: anotação mínima é necessária fora do tempo de execução KCSAN. No caso de um ouvinte de evento de pré-condição, qualquer omissão leva a falsos positivos, o que é particularmente importante no contexto do kernel que inclui mecanismos de tempo personalizados.
- Detecção de gravações dinâmicas de dispositivos: Ao verificar os valores dos dados durante a configuração do ponto de controle, as gravações dinâmicas de dispositivos também podem ser detectadas.