Udviklere fra Cloudflare om at udføre arbejde med at optimere ydeevnen af diskkryptering i Linux-kernen. Som et resultat var de forberedte for delsystem og Crypto API, som gjorde det muligt at mere end fordoble læse- og skrivegennemstrømningen i den syntetiske test, samt halvere latens. Når det blev testet på rigtig hardware, blev krypteringsomkostningerne reduceret til næsten det niveau, der blev observeret, når man arbejdede med en disk uden datakryptering.
Cloudflare bruger dm-crypt til at kryptere data på lagerenheder, der bruges til at cache indhold på CDN. Dm-crypt fungerer på blokenhedsniveau og krypterer skrive-I/O-anmodninger og dekrypterer læseanmodninger, der fungerer som et lag mellem blokenheden og filsystemdriveren.
For at evaluere ydeevnen af dm-crypt ved hjælp af pakken Vi målte hastigheden af at arbejde med krypterede og ukrypterede partitioner på en RAM-disk placeret i RAM for at eliminere udsving i diskens ydeevne og fokusere på kodeydeevne. For ukrypterede partitioner forblev læse- og skriveydeevnen på 1126 MB/s, men hastigheden faldt, når kryptering blev aktiveret 7 i tid og udgjorde 147 MB/s.
Først opstod der mistanke om brugen af ineffektive algoritmer i kernekryptosystemet. Men testene brugte den hurtigste algoritme, aes-xts, med 256 krypteringsnøgler, hvis ydeevne ved kørsel af "cryptsetup benchmark" er mere end dobbelt så høj som resultatet opnået ved test af en RAM-disk. Eksperimenter med dm-crypt-flag til justering af ydeevne gav ikke resultater: Når du brugte flaget "--perf-same_cpu_crypt", faldt ydeevnen endda til 136 MB/s, og når du specificerede flaget "--perf-submit_from_crypt_cpus" steg det kun til 166 MB/s.
En dybere analyse af driftslogikken viste, at dm-crypt ikke er så simpelt, som det ser ud til - når der kommer en skriveanmodning fra FS-driveren, behandler dm-crypt den ikke med det samme, men placerer den i "kcryptd"-køen, hvilket er ikke analyseret med det samme, men når det er passende tidspunkt. Fra køen sendes anmodningen til Linux Crypto API for at udføre kryptering. Men da Crypto API'en bruger en asynkron eksekveringsmodel, udføres kryptering heller ikke med det samme, men uden om en anden kø. Efter kryptering er fuldført, kan dm-crypt forsøge at sortere ventende skriveanmodninger ved hjælp af et søgetræ . Til sidst samler en separat kernetråd igen, med en vis forsinkelse, de akkumulerede I/O-anmodninger op og sender dem til blokenhedsstakken.
Ved læsning tilføjer dm-crypt først en anmodning til "kcryptd_io"-køen for at modtage data fra drevet. Efter nogen tid bliver dataene tilgængelige og placeres i "kcryptd"-køen til dekryptering.
Kcryptd sender en anmodning til Linux Crypto API, som dekrypterer informationen asynkront. Forespørgsler går ikke altid igennem alle køerne, men i værste fald ender en skriveanmodning i kø op til 4 gange, og en læseanmodning op til 3 gange. Hvert hit i køen forårsager forsinkelser, som er hovedårsagen til det betydelige fald i dm-crypt-ydeevnen.
Brugen af kø skyldes behovet for at arbejde under forhold, hvor der opstår afbrydelser. I 2005, da dm-crypts nuværende købaserede driftsmodel blev implementeret, var Crypto API'en endnu ikke asynkron. Efter at Crypto API blev overført til en asynkron eksekveringsmodel, begyndte der i det væsentlige at blive brugt dobbelt beskyttelse. Der blev også indført køer for at spare forbrug af kernestakken, men efter dens stigning i 2014 mistede disse optimeringer deres relevans. En ekstra kø "kcryptd_io" blev introduceret for at overvinde flaskehalsen, hvilket resulterede i at vente på hukommelsesallokering, når et stort antal anmodninger ankommer. I 2015 blev der indført en ekstra sorteringsfase, da krypteringsanmodninger på multiprocessorsystemer kunne gennemføres ude af drift (i stedet for sekventiel adgang til disken blev adgangen udført i tilfældig rækkefølge, og CFQ-planlæggeren fungerede ikke effektivt). I øjeblikket, når du bruger SSD-drev, har sortering mistet sin betydning, og CFQ-planlæggeren bruges ikke længere i kernen.
I betragtning af, at moderne drev er blevet hurtigere og smartere, er ressourcedistributionssystemet i Linux-kernen blevet revideret, og nogle undersystemer er blevet redesignet, siger Cloudflare-ingeniører dm-crypt har en ny driftstilstand, der eliminerer brugen af unødvendige køer og asynkrone opkald. Tilstanden aktiveres af et separat flag "force_inline" og bringer dm-crypt til form af en simpel proxy, der krypterer og dekrypterer indgående anmodninger. Interaktion med Crypto API er blevet optimeret ved eksplicit at vælge krypteringsalgoritmer, der fungerer i synkron tilstand og ikke bruger anmodningskøer. At arbejde synkront med Crypto API var der et modul, der giver dig mulighed for at bruge FPU/AES-NI til acceleration og direkte videresender krypterings- og dekrypteringsanmodninger.
Som følge heraf var det ved test af en RAM-disk muligt at mere end fordoble ydelsen af dm-crypt - ydelsen steg fra 294 MB/s (2 x 147 MB/s) til 640 MB/s, hvilket er meget tæt på ydeevnen af bare kryptering (696 MB/s).
Ved test af belastning på rigtige servere viste den nye implementering ydeevne meget tæt på konfigurationen, der kørte uden kryptering, og aktivering af kryptering på servere med Cloudflare-cache havde ingen effekt på responshastigheden. I fremtiden planlægger Cloudflare at overføre de forberedte patches til Linux-hovedkernen, men inden da skal de omarbejdes, da de er optimeret til en specifik belastning og ikke dækker alle applikationsområder, for eksempel kryptering på lav -strøm indlejrede enheder.
Kilde: opennet.ru