Clang vs. Clang

Clang vs. Clang: Não irrite o Clang

• Este é um post de blog sobre experimentos com o Clang
• Ao examinar mudanças recentes no LLVM e no GCC relacionadas à otimização de compiladores, vemos otimizações, testes de otimização, correções de testes e correções de bugs
• Autores de compiladores tendem a não querer se responsabilizar pelos bugs que introduzem
• Otimizações de compilador não contribuem muito para melhorias reais de desempenho

Problemas das otimizações de compilador

• É raro que um compilador otimizado realmente melhore o desempenho
• Por exemplo, a implementação avx2 do kyber768 é 4 vezes mais rápida do que o código compilado por um compilador otimizado
• Segundo a lei de Todd A. Proebsting, otimizações de compilador quase não contribuem para o desempenho computacional
• Os resultados de benchmark de Arseny Kapoulkine chegam a uma conclusão semelhante

Problemas de segurança

• Compiladores otimizados podem causar não apenas bugs tradicionais, mas também problemas de segurança como vazamentos de tempo
• Segundo um artigo da EuroS&P de 2018, uma atualização de compilador pode abrir canais temporais e tornar código seguro vulnerável
• Foi relatado um ataque de temporização bem-sucedido em código compilado a partir do código de referência do Kyber com opções de otimização do Clang 15 ou superior

Ferramenta TIMECOP

• O TIMECOP 2 é integrado ao framework de testes criptográficos SUPERCOP e faz varredura automática de desvios condicionais derivados de segredos
• Diferença entre o TIMECOP 1 e o TIMECOP 2: o TIMECOP 2 marca automaticamente a saída do RNG como secreta e é executado em múltiplos núcleos

Escrevendo código em tempo constante

• Em julho de 2024, foi apresentada uma palestra sobre como escrever código em tempo constante
• São explicadas as funções de tempo constante fornecidas pelo libmceliece e pelo SUPERCOP
• Por exemplo, a função crypto_uint32_bitmod_mask(x,j) impede que o compilador reconheça um resultado de 1 bit

Como prevenir problemas de otimização de compilador

• Uma das formas de evitar que o compilador introduza vazamentos de tempo é distribuir bibliotecas em linguagem assembly
• No entanto, linguagem assembly pode dificultar a auditoria da correção do software
• Está em busca uma forma de introduzir rapidamente em código C, C++ etc. mecanismos para evitar vazamentos de tempo

Patch clang-vs-clang

• Foi escrito um patch para a ferramenta de otimização do LLVM que escaneia &1 e >>31 e exibe mensagens de aviso
• Por exemplo, uma mensagem de aviso é exibida no código x >>= 31

Conclusão

• Otimizações de compilador não contribuem muito para melhorar o desempenho e podem causar problemas de segurança
• É preciso usar ferramentas como o TIMECOP para escrever código em tempo constante e prevenir problemas de otimização de compilador

Resumo do GN⁺

• Este texto trata dos problemas e dos riscos de segurança das otimizações de compilador
• Destaca que otimizações de compilador não contribuem muito para melhorias reais de desempenho e podem causar problemas de segurança
• Apresenta a ferramenta TIMECOP e formas de escrever código em tempo constante para prevenir problemas de segurança
• Também propõe distribuir bibliotecas em linguagem assembly como forma de prevenir problemas de otimização de compilador
• Outros projetos relacionados na área incluem compiladores voltados à segurança, como FaCT e Jasmin

[GN⁺]

Comentários do Hacker News

• Autores de compiladores não se responsabilizam por bugs causados por otimizações

  • De acordo com o padrão da linguagem, esses bugs são considerados culpa do programador
  • Isso é uma evidência de que não se trata de um bug

• Concorda com a opinião de Bernstein, mas às vezes ele segue na direção errada

  • Os benefícios da otimização variam conforme o caso de uso
  • Há reclamações de que compiladores C não consideram significados que a linguagem não consegue expressar
  • Isso pode ser resumido na conclusão: "use uma linguagem capaz de expressar o significado de que você precisa"

• C e C++ não são adequados para escrever algoritmos que exigem garantia de tempo constante

  • O padrão quase não tem conceito de tempo real
  • Culpar os desenvolvedores de compiladores é mirar na direção errada

• Em CPUs Intel, nem o clang nem qualquer outra coisa conseguem gerar código correto em modo usuário

  • Não é possível configurar o DOITM

• Não concorda com a afirmação de que autores de compiladores não se responsabilizam por bugs

  • Isso é um mal-entendido básico sobre o "comportamento indefinido" em C

• O clang tem o atributo clang::optnone, que permite desativar otimizações por função

  • O GCC tem o atributo gnu::optimize, que permite definir o nível de otimização
  • clang::no_builtins desativa otimizações de memcpy e memset

• Há tanto comportamento indefinido em C que isso pode levar à migração para outras linguagens

  • Em Python, a ordem de objetos set não é importante
  • Compiladores C tentam otimizar analisando padrões de código
  • Isso pode oferecer melhor desempenho de forma semelhante à solução do problema do telescópio Hubble

• Concorda com o objetivo dos especialistas em criptografia, mas compiladores de propósito geral não levam isso em conta

  • Pode ser necessário um compilador especializado

• É verdade que algumas linguagens e compiladores não são adequados para escrever rotinas criptográficas de tempo constante

  • Concluir que todos os compiladores e linguagens de assembly são ruins está errado
  • É preciso escrever um compilador e uma linguagem simples e específicos para o domínio

• No exemplo de uma função específica, ocorre comportamento indefinido quando a entrada é SIZE_T_MAX

  • Há muitos bugs desse tipo, mas na prática isso não é importante