Udviklere fra Cloudflare har arbejdet på at optimere ydelsen af disk-kryptering i Linux-kernen. Som et resultat er der blevet forberedt til subsystemet og Crypto API, som i en syntetisk test forsøgte at fordoble båndbredden ved læsning og skrivning samt halvere latensen. Under testning på faktisk hardware lykkedes det at reducere overhead fra kryptering næsten til niveauet, der observeres ved brug af disk uden datakryptering.
Cloudflare bruger dm-crypt til at kryptere data på lagringsenheder, der anvendes til caching af indhold i CDN-netværket. Dm-crypt opererer på blokniveau og udfører kryptering af skrive- og læseforespørgsler, hvilket fungerer som et lag mellem blokenheden og filsystemdriveren.
For at evaluere ydelsen af dm-crypt ved hjælp af pakken blev der målt hastigheden ved arbejde med krypterede og ukrypterede partitioner på en RAM-disk, der blev placeret i RAM for at undgå udsving i diskydelse og fokusere på kodeydelse. For de ukrypterede partitioner holdt læse- og skriveydelsen sig på niveauet 1126 MB/s, men da kryptering blev aktiveret, faldt hastigheden med 7 gange og endte på 147 MB/s.
I starten opstod der mistanke om brug af ineffektive algoritmer i kernens kryptosystem. Men der blev brugt den hurtigste algoritme aes-xts med en 256-bit krypteringsnøgle i testene, hvis ydelse ved udførelse af "cryptsetup benchmark" er mere end dobbelt så høj som den opnåede ved test af RAM-disk. Eksperimenter med dm-crypt flags for performance tuning gav ingen resultater: brug af flaget "—perf-same_cpu_crypt" reducerede ydelsen til 136 MB/s, og med flaget "—perf-submit_from_crypt_cpus" steg den kun til 166 MB/s.
En dybere analyse af logikken bag arbejdet viste, at dm-crypt ikke er så enkelt, som det ser ud — når der modtages en skriveanmodning fra filsystemdriveren, behandler dm-crypt den ikke straks, men placerer den i køen "kcryptd", som ikke behandles med det samme, men på det passende tidspunkt. Herfra sendes anmodningen til Linux Crypto API for udførelse af kryptering. Men da Crypto API bruger en asynkron udførelsesmodel, udføres krypteringen heller ikke straks, men omgår endnu en kø. Efter afslutningen af krypteringen kan dm-crypt forsøge at sortere de ventende skriveanmodninger ved hjælp af et søgetræ. . Til sidst fanger en særskilt tråd i kernen igen med en vis forsinkelse de akkumulerede input/output-anmodninger og sender dem til stakken af blokenheden.
Ved læsning tilføjer dm-crypt først anmodningen om at hente data fra lageret til køen "kcryptd_io". Efter et stykke tid bliver dataene tilgængelige og placeres i køen "kcryptd" til dekryptering.
Kcryptd sender anmodningen til Linux Crypto API, som dekrypterer oplysningerne i asynkron tilstand. Anmodninger passerer ikke altid gennem alle køer, men i værste fald kan en skriveanmodning sidde fast i køerne op til 4 gange, mens en læseanmodning kan sidde fast op til 3 gange. Hvert indtræden i køen medfører forsinkelser, som er den centrale årsag til den betydelige reduktion i ydeevnen for dm-crypt.
Anvendelsen af køer er begrundet i nødvendigheden af at arbejde under forhold med afbrydelser. I 2005, da den nuværende model for dm-crypt baseret på køer blev implementeret, var Crypto API endnu ikke asynkron. Efter overgangen af Crypto API til en asynkron udførelsesmodel blev der reelt indført en dobbelt beskyttelse. Køer blev også indført for at spare på forbruget af kernestakken, men efter stigning i 2014 mistede disse optimeringer relevans. En supplerende kø, 'kcryptd_io', blev introduceret for at overvinde flaskehalse, der førte til ventetid ved tildeling af hukommelse ved stor mængde anmodninger. I 2015 blev der yderligere tilføjet en sorteringsfase, da krypteringsanmodninger på multiprocessorsystemer kunne afsluttes uden at overholde den sende rækkefølge (i stedet for sekventiel adgang til disken, blev der tilgået i tilfældig rækkefølge, og CFQ-planlæggeren fungerede også ineffektivt). I dag har sortering mistet sin betydning ved brug af SSD-enheder, og CFQ-planlæggeren bruges ikke længere i kernen.
I betragtning af at moderne lagringsenheder er blevet hurtigere og mere intelligente, er ressourcefordelingssystemet i Linux-kernen blevet revideret, og nogle undersystemer er blevet omarbejdet af ingeniører fra Cloudflare. I dm-crypt er der en ny driftsform, der er fri for unødvendige køer og asynkrone kald. Indstillingen aktiveres med et separat flag 'force_inline' og konverterer dm-crypt til en simpel proxy, der krypterer og dekrypterer modtagne anmodninger. Interaktionen med Crypto API er blevet optimeret ved et eksplicit valg af krypteringsalgoritmer, der fungerer i synkron tilstand og ikke bruger anmodningskøer. For synkron drift med Crypto API blev der. en modul, der gør det muligt at bruge FPU/AES-NI til acceleration og direkte videresender krypterings- og dekrypteringsanmodninger.
Som et resultat lykkedes det under testning af RAM-disk at øge ydeevnen af dm-crypt med mere end det dobbelte — ydeevnen steg fra 294 MB/s (2 x 147 MB/s) til 640 MB/s, hvilket er meget tæt på ydeevnen af rå kryptering (696 MB/s).
Ved belastningstest af virkelige servere viste den nye implementering en ydeevne, der var meget tæt på konfigurationen, der kørte uden kryptering, og aktivering af kryptering på servere med Cloudflare-cache påvirkede slet ikke svartiden. I fremtiden planlægger Cloudflare at overføre de forberedte patches til den centrale Linux-kern, men før dette skal de revideres, da de er optimeret til en bestemt belastning og ikke dækker alle anvendelsesområder, såsom kryptering på lavkraftede indlejrede enheder.
Kilde: opennet.ru
