Clang contre Clang

Clang vs. Clang : n’énervez pas Clang

• Il s’agit d’un billet de blog consacré à des expérimentations sur Clang
• En examinant les récents changements dans LLVM et GCC liés à l’optimisation des compilateurs, on y trouve des optimisations, des tests d’optimisation, des corrections de tests, des corrections de bugs, etc.
• Les auteurs de compilateurs ne veulent pas assumer la responsabilité des bugs qu’ils ont introduits
• Les optimisations de compilateur contribuent peu aux gains de performance réels

Les problèmes des optimisations de compilateur

• Il est rare qu’un compilateur optimisé améliore réellement les performances
• Par exemple, l’implémentation avx2 de kyber768 est 4 fois plus rapide que le code compilé par un compilateur optimisé
• Selon la loi de Todd A. Proebsting, les optimisations de compilateur ne contribuent presque pas aux performances de calcul
• Les résultats de benchmark d’Arseny Kapoulkine arrivent à une conclusion similaire

Problèmes de sécurité

• Les compilateurs optimisés peuvent provoquer non seulement des bugs traditionnels, mais aussi des problèmes de sécurité comme des fuites temporelles
• Selon un article d’EuroS&P 2018, une mise à niveau du compilateur peut ouvrir des canaux temporels et rendre du code sécurisé vulnérable
• Une attaque temporelle réussie a été signalée dans le code de référence de Kyber compilé avec les options d’optimisation de Clang 15 et versions ultérieures

Outil TIMECOP

• TIMECOP 2 est intégré au framework de test cryptographique SUPERCOP et analyse automatiquement les branchements conditionnels dérivés de secrets
• Différence entre TIMECOP 1 et TIMECOP 2 : TIMECOP 2 marque automatiquement la sortie du RNG comme secrète et s’exécute sur plusieurs cœurs

Écriture de code en temps constant

• Une conférence sur la manière d’écrire du code en temps constant a eu lieu en juillet 2024
• Présentation des fonctions en temps constant fournies par libmceliece et SUPERCOP
• Par exemple, la fonction crypto_uint32_bitmod_mask(x,j) empêche le compilateur de reconnaître un résultat sur 1 bit

Prévenir les problèmes liés aux optimisations de compilateur

• Une façon d’empêcher le compilateur d’introduire des fuites temporelles consiste à distribuer les bibliothèques en langage assembleur
• Cependant, le langage assembleur peut rendre plus difficile l’audit de la correction du logiciel
• Une réflexion est en cours sur la manière d’introduire rapidement du code de prévention des fuites temporelles dans du code C, C++, etc.

Patch clang-vs-clang

• Un patch a été écrit pour l’outil d’optimisation LLVM afin d’analyser &1 et >>31 et d’afficher des messages d’avertissement
• Par exemple, un message d’avertissement est affiché pour le code x >>= 31

Conclusion

• Les optimisations de compilateur contribuent peu à l’amélioration des performances et peuvent causer des problèmes de sécurité
• Il faut utiliser des outils comme TIMECOP, écrire du code en temps constant et prévenir les problèmes liés aux optimisations de compilateur

Résumé de GN⁺

• Cet article traite des problèmes et des risques de sécurité liés aux optimisations de compilateur
• Il souligne que les optimisations de compilateur contribuent peu aux gains de performance réels et peuvent causer des problèmes de sécurité
• Il présente l’outil TIMECOP et des méthodes d’écriture de code en temps constant pour prévenir ces problèmes de sécurité
• Il propose aussi de distribuer des bibliothèques en langage assembleur pour prévenir les problèmes liés aux optimisations de compilateur
• Parmi les autres projets du domaine, on trouve des compilateurs orientés sécurité comme FaCT et Jasmin

[GN⁺]

Commentaires sur Hacker News

• Les auteurs de compilateurs n’assument pas la responsabilité des bugs provoqués par les optimisations

  • Selon le standard du langage, ces bugs sont considérés comme la faute du programmeur
  • C’est la preuve qu’il ne s’agit pas d’un bug

• D’accord avec l’avis de Bernstein, mais il part parfois dans la mauvaise direction

  • Les bénéfices de l’optimisation varient selon le cas d’usage
  • Certains reprochent aux compilateurs C de ne pas prendre en compte des significations qui ne peuvent pas être exprimées dans le langage
  • On peut résumer cela par la conclusion suivante : « utilisez un langage qui permet d’exprimer la sémantique dont vous avez besoin »

• C et C++ ne conviennent pas à l’écriture d’algorithmes nécessitant une garantie de temps constant

  • Le standard n’a pratiquement aucune notion de temps réel
  • Accuser les développeurs de compilateurs est une mauvaise piste

• Sur les CPU Intel, ni clang ni quoi que ce soit d’autre ne peut générer du code correct en mode utilisateur

  • Il est impossible de configurer DOITM

• Désaccord avec l’affirmation selon laquelle les auteurs de compilateurs ne sont pas responsables des bugs

  • Cela repose sur une incompréhension fondamentale du concept de « comportement indéfini » en C

• clang dispose de l’attribut clang::optnone, qui permet de désactiver les optimisations fonction par fonction

  • GCC dispose de l’attribut gnu::optimize, qui permet de définir le niveau d’optimisation
  • clang::no_builtins désactive les optimisations de memcpy et memset

• Il y a tellement de comportements indéfinis en C que cela peut pousser à passer à un autre langage

  • En Python, l’ordre d’un objet set n’a pas d’importance
  • Les compilateurs C analysent les motifs du code pour tenter d’optimiser
  • Cela peut offrir de meilleures performances, d’une manière comparable à la résolution du problème du télescope Hubble

• D’accord avec l’objectif des experts en cryptographie, mais les compilateurs généralistes n’en tiennent pas compte

  • Des compilateurs spécialisés peuvent être nécessaires

• Il est vrai que certains langages et compilateurs ne conviennent pas à l’écriture de routines cryptographiques en temps constant

  • En conclure que tous les compilateurs et tous les langages autres que l’assembleur sont mauvais est erroné
  • Il faut écrire un compilateur et un langage spécialisés simples pour ce domaine

• Dans un exemple de fonction précis, une entrée SIZE_T_MAX provoque un comportement indéfini

  • Il existe beaucoup de bugs de ce type, mais en pratique ils n’ont pas vraiment d’importance