Entwickler von Cloudflare über die Durchführung von Arbeiten zur Optimierung der Leistung der Festplattenverschlüsselung im Linux-Kernel. Infolgedessen wurden für das Subsystem und Crypto API vorbereitet, die in einem synthetischen Test die Durchsatzrate beim Lesen und Schreiben mehr als verdoppelt und außerdem die Latenzen halbiert haben. Bei Tests auf realer Hardware konnten die Kosten der Verschlüsselung nahezu auf das Niveau reduziert werden, das bei der Arbeit mit einer unverschlüsselten Festplatte beobachtet wird.
Cloudflare verwendet dm-crypt zur Verschlüsselung von Daten auf Speichermedien, die zum Cachen von Inhalten im CDN-Netzwerk genutzt werden. Dm-crypt arbeitet auf Blockgeräteebene und führt die Verschlüsselung von Schreib-I/O-Anfragen sowie die Entschlüsselung von Leseanforderungen durch, indem es als Schicht zwischen dem Blockgerät und dem Dateisystemtreiber fungiert.
Zur Bewertung der Leistung von dm-crypt mithilfe des Pakets wurden die Geschwindigkeiten von verschlüsselten und unverschlüsselten Partitionen auf einem RAM-Disk gemessen, die im RAM platziert wurde, um Leistungsschwankungen von Festplatten auszuschließen und sich auf die Leistung des Codes zu konzentrieren. Für unverschlüsselte Partitionen lag die Lese- und Schreibleistung bei 1126 MB/s, aber mit aktivierter Verschlüsselung sank die Geschwindigkeit siebenfach und betrug 147 MB/s.
Zunächst gab es Verdacht auf die Verwendung ineffizienter Algorithmen im Kryptosystem des Kernels. Aber bei den Tests wurde der schnellste Algorithmus aes-xts mit 256-Bit-Verschlüsselungsschlüssel verwendet, dessen Leistung bei der Ausführung des „cryptsetup benchmark“ mehr als doppelt so hoch ist wie das im RAM-Disk-Test erzielte Ergebnis. Experimente mit den Flags von dm-crypt zur Leistungsoptimierung lieferten keine Ergebnisse: Bei Verwendung des Flags „—perf-same_cpu_crypt“ sank die Leistung sogar auf 136 MB/s, während sie bei Angabe des Flags „—perf-submit_from_crypt_cpus“ nur auf 166 MB/s stieg.
Eine tiefere Analyse der Funktionsweise hat gezeigt, dass dm-crypt nicht so einfach ist, wie es scheint – wenn ein Schreibbefehl vom Dateisystemtreiber eingeht, verarbeitet dm-crypt ihn nicht sofort, sondern stellt ihn in die "kcryptd"-Warteschlange, die nicht sofort abgearbeitet wird, sondern erst zu einem passenden Zeitpunkt. Aus der Warteschlange wird die Anfrage an die Linux Crypto API zur Durchführung der Verschlüsselung gesendet. Da die Crypto API ein asynchrones Ausführungsmodell verwendet, erfolgt auch die Verschlüsselung nicht sofort und umgeht eine weitere Warteschlange. Nach Abschluss der Verschlüsselung kann dm-crypt versuchen, die wartenden Schreibanfragen mithilfe eines Suchbaums zu sortieren. . Am Ende greift ein separater Kern-Thread nach einer bestimmten Verzögerung auf die angesammelten Ein- / Ausgabeverbindungen zu und sendet sie an den Blockgeräte-Stack.
Beim Lesen fügt dm-crypt zunächst in die Warteschlange "kcryptd_io" eine Anfrage zum Abrufen von Daten vom Speichergerät ein. Nach einiger Zeit sind die Daten verfügbar und werden in die Warteschlange "kcryptd" zur Entschlüsselung gelegt.
Kcryptd sendet die Anfrage an die Linux Crypto API, die die Informationen im asynchronen Modus entschlüsselt. Anfragen durchlaufen nicht immer alle Warteschlangen, aber im schlimmsten Fall verbleibt eine Schreibanfrage bis zu 4 Mal in den Warteschlangen, während eine Leseanfrage bis zu 3 Mal verbleibt. Jedes Eintreffen in der Warteschlange führt zu Verzögerungen, die die Hauptursache für den signifikanten Rückgang der Leistung von dm-crypt darstellen.
Die Verwendung von Warteschlangen ist durch die Notwendigkeit bedingt, unter Bedingungen von Unterbrechungen zu arbeiten. Im Jahr 2005, als das aktuelle Modell von dm-crypt auf der Basis von Warteschlangen implementiert wurde, war die Crypto API noch nicht asynchron. Nach der Umstellung der Crypto API auf ein asynchrones Ausführungsmodell wurde im Grunde genommen ein doppelter Schutz eingeführt. Warteschlangen wurden ebenfalls zur Einsparung des Kernstapels eingeführt, aber nach dessen Erhöhung im Jahr 2014 verloren diese Optimierungen ihre Relevanz. Eine zusätzliche Warteschlange "kcryptd_io" wurde eingeführt, um einen Engpass zu überwinden, der auftrat, wenn eine große Anzahl von Anfragen eintrat und auf die Zuweisung von Speicher gewartet werden musste. Im Jahr 2015 wurde zusätzlich eine Sortierungsphase eingeführt, da Verschlüsselungsanfragen in Mehrprozessorsystemen nicht in der Reihenfolge bearbeitet werden konnten, in der sie gesendet wurden (anstatt sequenziell auf die Festplatte zuzugreifen, wurde auf zufällige Weise zugegriffen und der CFQ-Scheduler arbeitete ineffizient). Derzeit hat die Sortierung bei der Verwendung von SSD-Speichern an Bedeutung verloren, und der CFQ-Scheduler wird im Kernel nicht mehr verwendet.
Angesichts der Tatsache, dass moderne Speicher schneller und intelligenter geworden sind, wurde das Ressourcenmanagementsystem im Linux-Kernel überarbeitet und einige Teilsysteme umgestaltet, Ingenieure von Cloudflare wurde in dm-crypt ein neuer Betriebsmodus eingeführt, der ohne überflüssige Warteschlangen und asynchrone Aufrufe auskommt. Der Modus wird durch ein separates Flag "force_inline" aktiviert und bringt dm-crypt in die Form eines einfachen Proxys, der eingehende Anfragen verschlüsselt und entschlüsselt. Der Umgang mit der Crypto API wurde optimiert durch die explizite Auswahl von Verschlüsselungsalgorithmen, die im synchronen Modus arbeiten und keine Anfragewarteschlangen verwenden. Für die synchrone Arbeit mit der Crypto API wurde ein Modul eingeführt, das die Verwendung von FPU/AES-NI zur Beschleunigung ermöglicht und Anfragen zur Verschlüsselung und Entschlüsselung direkt durchreicht.
Infolge dessen konnte die Leistung von dm-crypt bei Tests mit RAM-Disks um mehr als das Zweifache gesteigert werden – die Leistung stieg von 294 MB/s (2 x 147 MB/s) auf 640 MB/s, was sehr nah an der Leistung der reinen Verschlüsselung (696 MB/s) liegt.
Bei Belastungstests auf realen Servern zeigte die neue Implementierung eine Leistung, die der Konfiguration ohne Verschlüsselung sehr nahe kam, und die Aktivierung der Verschlüsselung auf Servern mit Cloudflare-Cache hatte keinen Einfluss auf die Reaktionsgeschwindigkeit. In Zukunft plant Cloudflare, die vorbereiteten Patches in den Hauptkern von Linux zu integrieren, muss diese jedoch zuvor überarbeiten, da sie für eine bestimmte Last optimiert sind und nicht alle Anwendungen abdecken, wie zum Beispiel die Verschlüsselung auf leistungsschwachen Embedded-Geräten.
Quelle: opennet.ru
