Clang gegen Clang

Clang vs. Clang: Verärgert Clang besser nicht

• Ein Blogbeitrag über ein Experiment zu Clang
• Ein Blick auf jüngste Änderungen in LLVM und GCC rund um Compiler-Optimierungen, darunter Optimierungen, Optimierungstests, Test-Fixes und Bugfixes
• Compiler-Autoren möchten keine Verantwortung für Bugs übernehmen, die sie selbst eingeführt haben
• Compiler-Optimierungen tragen kaum zu realen Leistungssteigerungen bei

Probleme bei Compiler-Optimierungen

• Optimierende Compiler verbessern die Performance nur selten
• Zum Beispiel ist die avx2-Implementierung von kyber768 viermal schneller als mit einem optimierenden Compiler kompilierter Code
• Nach Todd A. Proebstings Gesetz tragen Compiler-Optimierungen fast nichts zur Rechenleistung bei
• Auch die Benchmark-Ergebnisse von Arseny Kapoulkine kommen zu einem ähnlichen Schluss

Sicherheitsprobleme

• Optimierende Compiler können nicht nur klassische Bugs verursachen, sondern auch Sicherheitsprobleme wie Timing-Leaks
• Laut einem EuroS&P-Paper von 2018 können Compiler-Upgrades Timing-Kanäle öffnen und dadurch sicheren Code verwundbar machen
• Für den Kyber-Referenzcode wurden erfolgreiche Timing-Angriffe auf mit Clang 15 oder neuer und Optimierungsoptionen kompilierten Code gemeldet

Das Werkzeug TIMECOP

• TIMECOP 2 ist in das Kryptographie-Test-Framework SUPERCOP integriert und scannt automatisch nach bedingten Verzweigungen, die aus Geheimnissen abgeleitet sind
• Unterschied zwischen TIMECOP 1 und TIMECOP 2: TIMECOP 2 markiert RNG-Ausgaben automatisch als geheim und läuft auf mehreren Kernen

Schreiben von Constant-Time-Code

• Im Juli 2024 wurde ein Vortrag darüber gehalten, wie man Constant-Time-Code schreibt
• Erklärung der in libmceliece und SUPERCOP bereitgestellten Constant-Time-Funktionen
• Zum Beispiel sorgt die Funktion crypto_uint32_bitmod_mask(x,j) dafür, dass der Compiler das 1-Bit-Ergebnis nicht erkennt

Vorbeugung gegen Probleme durch Compiler-Optimierungen

• Eine Möglichkeit zu verhindern, dass Compiler Timing-Leaks einführen, ist die Auslieferung von Bibliotheken in Assembler
• Assembler kann allerdings die Überprüfung der Korrektheit von Software erschweren
• Es wird nach Wegen gesucht, Schutz gegen Timing-Leaks schnell in Code wie C und C++ einzubauen

Der Patch clang-vs-clang

• Für die LLVM-Optimierungswerkzeuge wurde ein Patch geschrieben, der nach &1 und >>31 scannt und Warnmeldungen ausgibt
• Zum Beispiel wird bei Code wie x >>= 31 eine Warnmeldung ausgegeben

Fazit

• Compiler-Optimierungen tragen kaum zu Leistungssteigerungen bei und können Sicherheitsprobleme verursachen
• Mit Werkzeugen wie TIMECOP sollte man Constant-Time-Code schreiben und Problemen durch Compiler-Optimierungen vorbeugen

Zusammenfassung von GN⁺

• Dieser Artikel behandelt die Probleme und Sicherheitsrisiken von Compiler-Optimierungen
• Er betont, dass Compiler-Optimierungen kaum zu realen Leistungssteigerungen beitragen und Sicherheitsprobleme verursachen können
• Er stellt das Werkzeug TIMECOP und Methoden zum Schreiben von Constant-Time-Code vor, um Sicherheitsprobleme zu vermeiden
• Als weitere Möglichkeit zur Vermeidung von Problemen durch Compiler-Optimierungen wird auch die Auslieferung von Bibliotheken in Assembler vorgeschlagen
• Weitere Projekte in diesem Bereich sind sicherheitsorientierte Compiler wie FaCT und Jasmin

[GN⁺]

Hacker-News-Kommentare

• Compiler-Autoren übernehmen keine Verantwortung für Bugs, die durch Optimierungen entstehen

  • Nach dem Sprachstandard gelten solche Bugs als Fehler des Programmierers
  • Das ist ein Beleg dafür, dass es sich nicht um einen Bug handelt

• Zustimmung zu Bernsteins Ansicht, aber sie geht manchmal in die falsche Richtung

  • Der Nutzen von Optimierungen hängt vom jeweiligen Anwendungsfall ab
  • Es gibt die Beschwerde, dass C-Compiler Semantik nicht berücksichtigen, die sich nicht in der Sprache ausdrücken lässt
  • Das lässt sich als Fazit zusammenfassen: „Verwende eine Sprache, in der sich die benötigte Semantik ausdrücken lässt“

• C und C++ sind ungeeignet, um Algorithmen zu schreiben, die Garantien für konstante Laufzeit benötigen

  • Der Standard kennt praktisch kein Echtzeitkonzept
  • Es ist der falsche Ansatz, Compiler-Entwickler dafür verantwortlich zu machen

• Auf Intel-CPUs können weder clang noch sonst etwas im User-Mode korrekten Code erzeugen

  • Es ist unmöglich, DOITM zu setzen

• Keine Zustimmung zu der Behauptung, dass Compiler-Autoren keine Verantwortung für Bugs tragen

  • Das beruht auf einem grundlegenden Missverständnis von C-„undefiniertem Verhalten“

• clang hat das Attribut clang::optnone, mit dem sich Optimierungen pro Funktion deaktivieren lassen

  • GCC hat das Attribut gnu::optimize, mit dem sich das Optimierungsniveau festlegen lässt
  • clang::no_builtins deaktiviert Optimierungen für memcpy und memset

• Wegen des vielen undefinierten Verhaltens in C könnte ein Wechsel zu anderen Sprachen sinnvoll sein

  • In Python ist die Reihenfolge von set-Objekten nicht wichtig
  • C-Compiler analysieren Code-Muster und versuchen darauf basierend zu optimieren
  • Das kann auf ähnliche Weise wie bei der Fehlerbehebung des Hubble-Teleskops bessere Performance liefern

• Zustimmung zum Ziel von Kryptoexperten, aber allgemeine Compiler berücksichtigen das nicht

  • Möglicherweise werden spezialisierte Compiler benötigt

• Es stimmt, dass einige Sprachen und Compiler ungeeignet sind, um Krypto-Routinen mit konstanter Laufzeit zu schreiben

  • Daraus zu schließen, dass alle Compiler und Nicht-Assembler-Sprachen schlecht sind, ist falsch
  • Man sollte einfache domänenspezifische Compiler und Sprachen schreiben

• Im Beispiel einer bestimmten Funktion tritt bei Eingabe von SIZE_T_MAX undefiniertes Verhalten auf

  • Es gibt viele solche Bugs, aber in der Praxis sind sie nicht wichtig