Zhvilluesit nga Cloudflare në lidhje me kryerjen e punës për të optimizuar performancën e kriptimit të diskut në kernelin Linux. Si rezultat, ata u përgatitën për nënsistem dhe Crypto API, i cili bëri të mundur më shumë se dyfishimin e xhiros së leximit dhe shkrimit në testin sintetik, si dhe përgjysmimin e vonesës. Kur u testua në harduer të vërtetë, kostoja e lartë e kriptimit u reduktua pothuajse në nivelin e vërejtur kur punoni me një disk pa kriptim të të dhënave.
Cloudflare përdor dm-crypt për të enkriptuar të dhënat në pajisjet ruajtëse të përdorura për të ruajtur përmbajtjen në CDN. Dm-crypt operon në nivelin e pajisjes së bllokut dhe kodon kërkesat e shkrimit I/O dhe deshifron kërkesat e leximit, duke vepruar si një shtresë midis pajisjes së bllokut dhe drejtuesit të sistemit të skedarëve.
Për të vlerësuar performancën e dm-crypt duke përdorur paketën Ne matëm shpejtësinë e punës me ndarje të koduara dhe të pakriptuara në një disk RAM të vendosur në RAM për të eliminuar luhatjet në performancën e diskut dhe për t'u fokusuar në performancën e kodit. Për ndarjet e pakriptuara, performanca e leximit dhe shkrimit mbeti në 1126 MB/s, por shpejtësia u ul kur u aktivizua enkriptimi 7 në kohë dhe arriti në 147 MB/s.
Në fillim, u ngrit dyshimi për përdorimin e algoritmeve joefikase në kriptosistemin e kernelit. Por testet përdorën algoritmin më të shpejtë, aes-xts, me 256 çelësa enkriptimi, performanca e të cilëve gjatë ekzekutimit të "benchmark cryptsetup" është më shumë se dy herë më e lartë se rezultati i marrë gjatë testimit të një disku RAM. Eksperimentet me flamujt dm-crypt për akordimin e performancës nuk dhanë rezultate: kur përdorni flamurin "--perf-same_cpu_crypt", performanca madje u ul në 136 MB/s dhe kur specifikohej flamuri "--perf-submit_from_crypt_cpus" u rrit vetëm deri në 166 MB/s.
Një analizë më e thellë e logjikës së funksionimit tregoi se dm-crypt nuk është aq e thjeshtë sa duket - kur një kërkesë për shkrim vjen nga drejtuesi FS, dm-crypt nuk e përpunon atë menjëherë, por e vendos atë në radhën "kcryptd", e cila nuk analizohet menjëherë, por në momentin e përshtatshëm. Nga radha, kërkesa dërgohet në Linux Crypto API për të kryer enkriptim. Por meqenëse Crypto API përdor një model ekzekutimi asinkron, enkriptimi gjithashtu nuk kryhet menjëherë, por duke anashkaluar një radhë tjetër. Pasi të përfundojë kriptimi, dm-crypt mund të përpiqet të renditë kërkesat për shkrim në pritje duke përdorur një pemë kërkimi . Në fund, një thread i veçantë i kernelit përsëri, me një vonesë të caktuar, merr kërkesat e grumbulluara për hyrje/dalje dhe i dërgon ato në stivën e pajisjes së bllokut.
Kur lexoni, dm-crypt së pari shton një kërkesë në radhën "kcryptd_io" për të marrë të dhëna nga disku. Pas ca kohësh, të dhënat bëhen të disponueshme dhe vendosen në radhën "kcryptd" për deshifrim.
Kcryptd dërgon një kërkesë në Linux Crypto API, i cili deshifron informacionin në mënyrë asinkrone. Kërkesat jo gjithmonë kalojnë nëpër të gjitha radhët, por në skenarin më të keq, një kërkesë për shkrim përfundon në radhë deri në 4 herë dhe një kërkesë për lexim deri në 3 herë. Çdo goditje në radhë shkakton vonesa, të cilat janë arsyeja kryesore për uljen e ndjeshme të performancës së dm-crypt.
Përdorimi i radhëve është për shkak të nevojës për të punuar në kushte ku ndodhin ndërprerje. Në vitin 2005, kur u zbatua modeli aktual i funksionimit i bazuar në radhë të dm-crypt, Crypto API nuk ishte ende asinkron. Pasi API Crypto u transferua në një model ekzekutimi asinkron, në thelb filloi të përdoret mbrojtja e dyfishtë. Radhët u prezantuan gjithashtu për të kursyer konsumin e pirgut të kernelit, por pas rritjes së tij në 2014, këto optimizime humbën rëndësinë e tyre. Një radhë shtesë "kcryptd_io" u prezantua për të kapërcyer pengesën që rezulton në pritjen e alokimit të memories kur mbërrijnë një numër i madh kërkesash. Në vitin 2015, u prezantua një fazë shtesë e renditjes, pasi kërkesat e kriptimit në sistemet me shumë procesorë mund të plotësoheshin jashtë rregullit (në vend të aksesit sekuencial në disk, qasja u krye në mënyrë të rastësishme dhe planifikuesi CFQ nuk funksionoi në mënyrë efikase). Aktualisht, kur përdorni disqet SSD, renditja ka humbur kuptimin e saj dhe planifikuesi CFQ nuk përdoret më në kernel.
Duke pasur parasysh që disqet moderne janë bërë më të shpejtë dhe më të zgjuar, sistemi i shpërndarjes së burimeve në kernelin Linux është rishikuar dhe disa nënsisteme janë ridizajnuar, inxhinierët e Cloudflare dm-crypt ka një mënyrë të re funksionimi që eliminon përdorimin e radhëve të panevojshme dhe thirrjeve asinkrone. Modaliteti aktivizohet nga një flamur i veçantë "force_inline" dhe sjell dm-crypt në formën e një përfaqësuesi të thjeshtë që kodon dhe deshifron kërkesat hyrëse. Ndërveprimi me Crypto API është optimizuar duke zgjedhur në mënyrë eksplicite algoritme enkriptimi që funksionojnë në modalitetin sinkron dhe nuk përdorin radhë kërkesash. Për të punuar në mënyrë sinkrone me Crypto API ekzistonte një modul që ju lejon të përdorni FPU/AES-NI për përshpejtim dhe të dërgoni drejtpërdrejt kërkesat e enkriptimit dhe deshifrimit.
Si rezultat, gjatë testimit të një disku RAM, ishte e mundur të dyfishohej performanca e dm-crypt - performanca u rrit nga 294 MB/s (2 x 147 MB/s) në 640 MB/s, që është shumë afër performanca e kriptimit të zhveshur (696 MB / s).
Gjatë testimit të ngarkesës në serverë realë, zbatimi i ri tregoi performancë shumë afër konfigurimit që funksiononte pa kriptim dhe aktivizimi i kriptimit në serverët me cache Cloudflare nuk kishte asnjë efekt në shpejtësinë e përgjigjes. Në të ardhmen, Cloudflare planifikon të transferojë arnimet e përgatitura në kernelin kryesor Linux, por para kësaj ato do të duhet të ripunohen, pasi ato janë të optimizuara për një ngarkesë specifike dhe nuk mbulojnë të gjitha fushat e aplikimit, për shembull, enkriptimin në nivel të ulët - pajisje të ngulitura me energji.
Burimi: opennet.ru