Entwickler von Cloudflare über die Durchführung von Arbeiten zur Optimierung der Leistung der Festplattenverschlüsselung im Linux-Kernel. Als Ergebnis wurden sie vorbereitet für Subsystem und Crypto API, die es ermöglichte, den Lese- und Schreibdurchsatz im synthetischen Test mehr als zu verdoppeln und die Latenz zu halbieren. Beim Test auf echter Hardware wurde der Verschlüsselungsaufwand auf fast das Niveau reduziert, das beim Arbeiten mit einer Festplatte ohne Datenverschlüsselung beobachtet wurde.
Cloudflare verwendet dm-crypt, um Daten auf Speichergeräten zu verschlüsseln, die zum Zwischenspeichern von Inhalten im CDN verwendet werden. Dm-crypt arbeitet auf Blockgeräteebene und verschlüsselt Schreib-E/A-Anfragen und entschlüsselt Leseanfragen, wobei es als Schicht zwischen dem Blockgerät und dem Dateisystemtreiber fungiert.
Um die Leistung von dm-crypt mithilfe des Pakets zu bewerten Wir haben die Arbeitsgeschwindigkeit mit verschlüsselten und unverschlüsselten Partitionen auf einer RAM-Disk im RAM gemessen, um Schwankungen in der Festplattenleistung zu beseitigen und uns auf die Codeleistung zu konzentrieren. Bei unverschlüsselten Partitionen blieb die Lese- und Schreibleistung bei 1126 MB/s, die Geschwindigkeit nahm jedoch ab, wenn die Verschlüsselung aktiviert war 7 zeitlich und betrug 147 MB/s.
Zunächst entstand der Verdacht, dass im Kernel-Kryptosystem ineffiziente Algorithmen zum Einsatz kommen. Bei den Tests wurde jedoch der schnellste Algorithmus, aes-xts, mit 256 Verschlüsselungsschlüsseln verwendet, dessen Leistung beim Ausführen des „Cryptsetup-Benchmarks“ mehr als doppelt so hoch ist wie das Ergebnis beim Testen einer RAM-Disk. Experimente mit dm-crypt-Flags zur Leistungsoptimierung brachten keine Ergebnisse: Bei Verwendung des Flags „--perf-same_cpu_crypt“ sank die Leistung sogar auf 136 MB/s, und bei Angabe des Flags „--perf-submit_from_crypt_cpus“ stieg sie nur an bis 166 MB/s.
Eine tiefere Analyse der Betriebslogik zeigte, dass dm-crypt nicht so einfach ist, wie es scheint – wenn eine Schreibanforderung vom FS-Treiber eintrifft, verarbeitet dm-crypt diese nicht sofort, sondern stellt sie in die „kcryptd“-Warteschlange, die wird nicht sofort analysiert, sondern zu einem geeigneten Zeitpunkt. Von der Warteschlange wird die Anfrage an die Linux Crypto API gesendet, um die Verschlüsselung durchzuführen. Da die Crypto API aber ein asynchrones Ausführungsmodell verwendet, erfolgt die Verschlüsselung auch nicht sofort, sondern unter Umgehung einer weiteren Warteschlange. Nachdem die Verschlüsselung abgeschlossen ist, versucht dm-crypt möglicherweise, ausstehende Schreibanfragen mithilfe eines Suchbaums zu sortieren . Am Ende holt wiederum ein eigener Kernel-Thread mit einer gewissen Verzögerung die angesammelten I/O-Anfragen ab und sendet sie an den Block-Device-Stack.
Beim Lesen fügt dm-crypt zunächst eine Anfrage zur „kcryptd_io“-Warteschlange hinzu, um Daten vom Laufwerk zu empfangen. Nach einiger Zeit stehen die Daten zur Verfügung und werden zur Entschlüsselung in die Warteschlange „kcryptd“ gestellt.
Kcryptd sendet eine Anfrage an die Linux Crypto API, die die Informationen asynchron entschlüsselt. Anfragen durchlaufen nicht immer alle Warteschlangen, aber im schlimmsten Fall landet eine Schreibanfrage bis zu 4 Mal in Warteschlangen, eine Leseanfrage bis zu 3 Mal. Jeder Treffer in der Warteschlange führt zu Verzögerungen, die der Hauptgrund für den erheblichen Leistungsabfall von dm-crypt sind.
Die Verwendung von Warteschlangen ist auf die Notwendigkeit zurückzuführen, unter Bedingungen zu arbeiten, in denen es zu Unterbrechungen kommt. Als im Jahr 2005 das aktuelle warteschlangenbasierte Betriebsmodell von dm-crypt implementiert wurde, war die Crypto API noch nicht asynchron. Nachdem die Crypto API auf ein asynchrones Ausführungsmodell umgestellt wurde, begann man damit, im Wesentlichen einen doppelten Schutz zu nutzen. Um den Verbrauch des Kernel-Stacks einzusparen, wurden auch Warteschlangen eingeführt. Nach der Erhöhung im Jahr 2014 verloren diese Optimierungen jedoch ihre Relevanz. Eine zusätzliche Warteschlange „kcryptd_io“ wurde eingeführt, um den Engpass zu überwinden, der dazu führt, dass bei einer großen Anzahl an Anfragen auf die Speicherzuweisung gewartet wird. Im Jahr 2015 wurde eine zusätzliche Sortierphase eingeführt, da Verschlüsselungsanforderungen auf Multiprozessorsystemen möglicherweise nicht in der richtigen Reihenfolge ausgeführt wurden (anstelle des sequentiellen Zugriffs auf die Festplatte erfolgte der Zugriff in zufälliger Reihenfolge und der CFQ-Scheduler funktionierte nicht effizient). Derzeit hat die Sortierung bei Verwendung von SSD-Laufwerken ihre Bedeutung verloren und der CFQ-Scheduler wird im Kernel nicht mehr verwendet.
Angesichts der Tatsache, dass moderne Laufwerke schneller und intelligenter geworden sind, wurde das Ressourcenverteilungssystem im Linux-Kernel überarbeitet und einige Subsysteme neu gestaltet, so die Cloudflare-Ingenieure dm-crypt verfügt über einen neuen Betriebsmodus, der die Verwendung unnötiger Warteschlangen und asynchroner Aufrufe eliminiert. 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. Die Interaktion mit der Crypto API wurde optimiert, indem explizit Verschlüsselungsalgorithmen ausgewählt wurden, die im synchronen Modus arbeiten und keine Anforderungswarteschlangen verwenden. Es gab eine Möglichkeit, synchron mit der Crypto API zu arbeiten ein Modul, das Ihnen die Nutzung von FPU/AES-NI zur Beschleunigung ermöglicht und Verschlüsselungs- und Entschlüsselungsanfragen direkt weiterleitet.
Dadurch konnte beim Test einer RAM-Disk die Leistung von dm-crypt mehr als verdoppelt werden – die Leistung stieg von 294 MB/s (2 x 147 MB/s) auf 640 MB/s, was sehr nahe daran liegt die Leistung der bloßen Verschlüsselung (696 MB/s).
Beim Testen der Auslastung auf realen Servern zeigte die neue Implementierung eine Leistung, die der ohne Verschlüsselung ausgeführten Konfiguration sehr nahe kam, und die Aktivierung der Verschlüsselung auf Servern mit Cloudflare-Cache hatte keine Auswirkungen auf die Antwortgeschwindigkeit. Zukünftig plant Cloudflare, die vorbereiteten Patches auf den Haupt-Linux-Kernel zu übertragen. Zuvor müssen sie jedoch überarbeitet werden, da sie für eine bestimmte Last optimiert sind und nicht alle Anwendungsbereiche abdecken, beispielsweise die Verschlüsselung auf niedriger Stufe -Eingebettete Geräte mit Strom versorgen.
Source: opennet.ru