Utviklere fra Cloudflare om å utføre arbeid for å optimalisere ytelsen til diskkryptering i Linux-kjernen. Som et resultat var de forberedt for delsystem og Crypto API, som gjorde det mulig å mer enn doble lese- og skrivegjennomstrømningen i den syntetiske testen, samt halvere ventetiden. Når den ble testet på ekte maskinvare, ble krypteringsoverhead redusert til nesten det nivået som ble observert når man arbeider med en disk uten datakryptering.
Cloudflare bruker dm-crypt for å kryptere data på lagringsenheter som brukes til å bufre innhold på CDN. Dm-crypt opererer på blokkenhetsnivå og krypterer skrive-I/O-forespørsler og dekrypterer leseforespørsler, og fungerer som et lag mellom blokkenheten og filsystemdriveren.
For å evaluere ytelsen til dm-crypt ved å bruke pakken Vi målte hastigheten på arbeidet med krypterte og ukrypterte partisjoner på en RAM-disk plassert i RAM for å eliminere svingninger i diskytelse og fokusere på kodeytelse. For ukrypterte partisjoner holdt lese- og skriveytelsen seg på 1126 MB/s, men hastigheten gikk ned når kryptering ble aktivert 7 ganger og utgjorde 147 MB/s.
Først oppsto det mistanke om bruk av ineffektive algoritmer i kjernekryptosystemet. Men testene brukte den raskeste algoritmen, aes-xts, med 256 krypteringsnøkler, hvis ytelse når du kjører "cryptsetup benchmark" er mer enn dobbelt så høy som resultatet oppnådd når du tester en RAM-disk. Eksperimenter med dm-crypt-flagg for ytelsesinnstilling ga ikke resultater: ved bruk av «--perf-same_cpu_crypt»-flagget, sank ytelsen til og med til 136 MB/s, og når man spesifiserte «--perf-submit_from_crypt_cpus»-flagget økte den bare til 166 MB/s.
En dypere analyse av driftslogikken viste at dm-crypt ikke er så enkelt som det ser ut til - når en skriveforespørsel kommer fra FS-driveren, behandler ikke dm-crypt den umiddelbart, men plasserer den i "kcryptd"-køen, som blir ikke analysert umiddelbart, men når det passer øyeblikk. Fra køen sendes forespørselen til Linux Crypto API for å utføre kryptering. Men siden Crypto API bruker en asynkron utførelsesmodell, utføres heller ikke kryptering umiddelbart, men omgår en annen kø. Etter at kryptering er fullført, kan dm-crypt forsøke å sortere ventende skriveforespørsler ved hjelp av et søketre . På slutten henter en egen kjernetråd igjen, med en viss forsinkelse, de akkumulerte I/O-forespørslene og sender dem til blokkenhetsstakken.
Ved lesing legger dm-crypt først til en forespørsel til "kcryptd_io"-køen for å motta data fra stasjonen. Etter en tid blir dataene tilgjengelige og plasseres i "kcryptd"-køen for dekryptering.
Kcryptd sender en forespørsel til Linux Crypto API, som dekrypterer informasjonen asynkront. Forespørsler går ikke alltid gjennom alle køene, men i verste fall havner en skriveforespørsel i kø opptil 4 ganger, og en leseforespørsel opptil 3 ganger. Hvert treff i køen forårsaker forsinkelser, som er hovedårsaken til den betydelige nedgangen i dm-crypt-ytelsen.
Bruk av kø skyldes behov for å jobbe under forhold hvor det oppstår avbrudd. I 2005, da dm-crypts nåværende købaserte driftsmodell ble implementert, var Crypto API ennå ikke asynkront. Etter at Crypto API ble overført til en asynkron utførelsesmodell, begynte i hovedsak dobbel beskyttelse å bli brukt. Køer ble også introdusert for å spare forbruk av kjernestabelen, men etter økningen i 2014 mistet disse optimaliseringene sin relevans. En ekstra kø "kcryptd_io" ble introdusert for å overvinne flaskehalsen som resulterte i å vente på minneallokering når et stort antall forespørsler kommer. I 2015 ble en ekstra sorteringsfase introdusert, siden krypteringsforespørsler på multiprosessorsystemer kunne fullføres ute av drift (i stedet for sekvensiell tilgang til disken ble tilgangen utført i tilfeldig rekkefølge, og CFQ-planleggeren fungerte ikke effektivt). For øyeblikket, når du bruker SSD-stasjoner, har sortering mistet sin betydning, og CFQ-planleggeren brukes ikke lenger i kjernen.
Med tanke på at moderne stasjoner har blitt raskere og smartere, har ressursdistribusjonssystemet i Linux-kjernen blitt revidert og noen delsystemer har blitt redesignet, sier Cloudflare-ingeniører dm-crypt har en ny driftsmodus som eliminerer bruken av unødvendige køer og asynkrone anrop. Modusen er aktivert av et eget flagg "force_inline" og bringer dm-crypt til form av en enkel proxy som krypterer og dekrypterer innkommende forespørsler. Interaksjon med Crypto API har blitt optimalisert ved eksplisitt å velge krypteringsalgoritmer som opererer i synkron modus og ikke bruker forespørselskøer. Å jobbe synkront med Crypto API det var en modul som lar deg bruke FPU/AES-NI for akselerasjon og direkte videresending av kryptering og dekrypteringsforespørsler.
Som et resultat, ved testing av en RAM-disk, var det mulig å mer enn doble ytelsen til dm-crypt - ytelsen økte fra 294 MB/s (2 x 147 MB/s) til 640 MB/s, som er svært nær ytelsen til bare kryptering (696 MB/s).
Ved testing av belastning på ekte servere viste den nye implementeringen ytelse svært nær konfigurasjonen som kjørte uten kryptering, og aktivering av kryptering på servere med Cloudflare-cache hadde ingen effekt på responshastigheten. I fremtiden planlegger Cloudflare å overføre de forberedte oppdateringene til hoved Linux-kjernen, men før det må de omarbeides, siden de er optimalisert for en spesifikk belastning og ikke dekker alle applikasjonsområder, for eksempel kryptering på lav -strøm innebygde enheter.
Kilde: opennet.ru