Google-Ingenieure das trägt zum Linux-Kernel bei haben angekündigt, Hunderte von "Race Conditions" im Kernel mit KCSAN entdeckt zu haben. Das Unternehmen arbeitet seit langem an AddressSanitizer, um Fehler im Zusammenhang mit Speicherbeschädigungen oder UndefinedBehaviorSanitizer für undefiniertes Verhalten im Code zu finden.
Diesmal Google bietet einen neuen "Race Conditions" -Detektor für den Linux-Kernel namens KCSAN an (Kernel Concurrency Sanitizer). Diese kritischen Sicherheitslücken sind nicht neu. In der Tat die Race-Bedingungen treten auf, wenn zwei oder mehr Threads im selben Prozess gleichzeitig auf denselben Speicherort zugreifen, wenn mindestens einer der Zugriffe geschrieben werden soll und wenn die Threads keine exklusiven Sperren verwenden, um ihren Zugriff auf diesen Speicher zu steuern.
Wenn diese Bedingungen erfüllt sind, ist die Zugriffsreihenfolge nicht deterministisch und die Berechnung kann abhängig von dieser Reihenfolge von einem Lauf zum anderen unterschiedliche Ergebnisse liefern.
Rennbedingungen werden zunehmend als gleichzeitige Zugriffsfehler angesehen und sind schwer zu duplizieren und in parallelen Programmen diagnostizieren. Der Linux-Kernel ist ein umfangreiches Softwaresystem, bei dem threadintensive Parallelität und nicht deterministisches Thread-Interleaving eher Wettbewerbsbedingungen unterliegen.
Einige Wettbewerbssituationen können harmlos sein, aber viele von ihnen, die bisher identifiziert wurden, gelten als Fehler.
Der Linux-Kernel bietet verschiedene Mechanismen, um diese Art von Bedingungen zu vermeiden und zu verwalten Da es Tools wie Thread Analyzer oder KTSAN (Kernel Thread Sanitizer) gibt, um kritische Ausführungsfehler im Linux-Kernel zu erkennen.
Google, das auch zum Linux-Kernel beiträgt, hat kürzlich KCSAN vorgeschlagen, ein neuer Race Conditions-Detektor für den Kernel, ähnlich wie KTSAN.
Laut Google konzentriert sich KCSAN darauf, Wettbewerbssituationen im Kernel-Code zu entdecken. Dieser dynamische Detektor für kritische Treffer ist eine Alternative zum Kernel Thread Sanitizer (KTSAN).
Gemäß der Erklärung von Google KCSAN basiert im Gegensatz zum KTSAN-Detektor auf Probenahmeüberwachungspunkten. Das ist ein kritischer Renndetektor vor dem Ereignis. Hauptprioritäten beim KCSAN-Design sind fehlende Fehlalarme, Skalierbarkeit und Einfachheit.
KCSAN verwendet Kompilierungswerkzeuge, um auf den Speicher zuzugreifen. KCSAN ist mit den Compilern GCC und Clang kompatibel. Für GCC ist Version 7.3.0 oder höher und für Clang Version 7.0.0 oder höher erforderlich.
Auf der GitHub-Seite des ProjektsMarco Elver von Google schrieb, dass sie mit KCSAN in Tests im letzten Monat in nur zwei Tagen mehr als 300 einzigartige Kernwettbewerbsituationen gefunden haben. KCSAN bietet verschiedene Konfigurationsoptionen, um das Verhalten anzupassen.
„Wir verwenden KCSAN seit mehreren Wochen über Syzkaller und haben viele Fehler gefunden. Zunächst haben wir im September 2019 in nur zwei Tagen mehr als 300 einzigartige Wettbewerbssituationen identifiziert “, schrieb er.
Google sagte, dass der Gesamtansatz auf DataCollider basiert, ein weiterer dynamischer Detektor für Wettbewerbssituationen in den Kernelmodulen. Im Gegensatz zu DataCollider verwendet KCSAN jedoch keine Hardwareüberwachungspunkte, sondern setzt auf Kompilierungswerkzeuge.
Die Überwachungspunkte werden mithilfe einer effizienten Codierung implementiert, in der Typ, Größe und Zugriffsadresse in einer langen Datei gespeichert sind. Die Vorteile der Verwendung flexibler Überwachungspunkte liegen in der Portabilität und der größeren Flexibilität bei der Einschränkung des Zugriffs, den ein Überwachungspunkt aktivieren kann.
Hier sind einige der wichtigsten Punkte, die KCSAN für Google gemacht hat:
- Hochleistung: Die KCSAN-Laufzeit ist minimal und erfordert nicht für jeden Zugriff eine gemeinsame Statussperre. Das Ergebnis ist eine viel bessere Leistung als KTSAN.
- Kein zusätzlicher Speicher: Laut Google ist kein Cache erforderlich. Die aktuelle Implementierung verwendet eine kleine Anzahl von Längen, um die Überwachungspunktinformationen zu codieren, was vernachlässigbar ist.
- Speicherbefehl: KCSAN kennt die Steuerungsregeln für das Linux-Kernel-Speichermodell (LKMM) nicht. Dies kann dazu führen, dass kritische Rennen verloren gehen (falsch negative Ergebnisse), verglichen mit einem Renndetektor vor dem Ereignis wie KTSAN
- Genauigkeit: Laut Google ist KCSAN ungenau, da es eine Stichprobenstrategie verwendet.
- Benötigt Anmerkung: Außerhalb der KCSAN-Laufzeit ist eine minimale Annotation erforderlich. Im Fall eines Ereignis-Listeners vor einer Bedingung führt jede Auslassung zu falsch positiven Ergebnissen, was besonders im Kontext des Kernels wichtig ist, der benutzerdefinierte Timing-Mechanismen enthält.
- Erkennung dynamischer Schreibvorgänge von Geräten: Durch Überprüfen der Datenwerte während der Einrichtung des Überwachungspunkts können auch dynamische Schreibvorgänge von Geräten erkannt werden.