A Cloudflare fejlesztői a Linux kernel lemeztitkosítási teljesítményoptimalizálási munkájáról beszéltek. Ennek eredményeként előkészítették az alrendszert és a Crypto API-t, amelyek lehetővé tették, hogy a szintetikus teszt során több mint kétszeresére növeljék az olvasási és írási átvitel képességét, valamint kétszer csökkentsék a késleltetéseket. Valódi hardveren végzett tesztelés során a titkosítással járó költségeket szinte a titkosítás nélküli lemez használatával megfigyelt szintre sikerült lecsökkenteni.
A Cloudflare a dm-crypt-ot használja az adatok titkosítására a tartalom gyorsítótárazására használt tárolókon a CDN-hálózatban. A dm-crypt blokk eszköz szinten működik, titkosítja az írási bemeneti/kimeneti kéréseket és dekriptionálja az olvasási kéréseket, mint egy réteg a blokk eszköz és a fájlrendszer illesztőprogram között.
A dm-crypt teljesítményének értékelésére a csomag segítségével mérték a titkosított és a nem titkosított partíciókkal végzett sebességet egy RAM lemezen, amely az RAM-ban található a meghajtók teljesítményváltozásának kizárása érdekében és a kód teljesítményére összpontosítva. A nem titkosított partíciók esetén az olvasási és írási teljesítmény 1126 MB/s szinten maradt, de titkosítás bekapcsolásakor a sebesség csökkent 7-szer és 147 MB/s-t tett ki.
Eleinte gyanú merült fel, hogy a kernel kriptoszisztémájában nem hatékony algoritmusokat használnak. De a tesztek során a leggyorsabb aes-xts algoritmust használták 256-os titkosítással, amelynek a »cryptsetup benchmark« végrehajtása során a teljesítménye több mint kétszerese a tesztelés RAM lemezének eredményének. A dm-crypt teljesítményfinomító zászlókkal végzett kísérletek nem eredményeztek javulást: a „—perf-same_cpu_crypt” zászló használatakor a teljesítmény 136 MB/s sebességre csökkent, míg a „—perf-submit_from_crypt_cpus” zászlóval a teljesítmény csak 166 MB/s-ra növekedett.
A mélyebb elemzés rámutatott arra, hogy a dm-crypt nem olyan egyszerű, mint amilyennek látszik — amikor a fájlrendszer illesztőprogramtól írási kérést kap, a dm-crypt nem dolgozza fel azt azonnal, hanem egy "kcryptd" sorba helyezi, amelyet nem azonnal kezel, hanem amikor megfelelő pillanat adódik. A sorból a kérés a Linux Crypto API-hoz kerül a titkosítás végrehajtására. Mivel a Crypto API aszinkron végrehajtási modellt használ, a titkosítás sem történik azonnal, hanem egy további sor kivárása után. A titkosítás befejezése után a dm-crypt megkísérli a várakozó írási kérések rendezését egy keresőfa segítségével. . A végén egy külön szál ismét bizonyos késéssel megérinti a felhalmozódott bemeneti/kimeneti kéréseket, és továbbítja azokat a blokkeszköz veremére.
Olvasáskor először a dm-crypt egy "kcryptd_io" sorba helyezi a kérést az adatok megszerzésére a tárolóból. Egy idő után az adatok elérhetővé válnak, és a "kcryptd" sorba kerülnek a dekódolásra.
A Kcryptd elküldi a kérést a Linux Crypto API-hoz, amely aszinkron módban dekódolja az információt. A kérések nem mindig haladnak át minden soron, de a legrosszabb forgatókönyvben az írási kérés akár 4-szer is megakadhat a sorokban, míg az olvasási kérés legfeljebb 3-szor. Minden sorba került kérés késleltetést okoz, amelyek a dm-crypt jelentős teljesítménycsökkenésének kulcsfontosságú okát jelentik.
A sorok használata a megszakításokkal teli környezetek munkájának szükségszerűségével magyarázható. 2005-ben, amikor a dm-crypt aktuális munkamodellje a sorok alapjára épült, a Crypto API még nem volt aszinkron. A Crypto API aszinkron végrehajtási modellre való átállítása után lényegében kettős védelem lépett életbe. A sorokat a kernel veremfogyasztásának csökkentésére is bevezették, de 2014-re a verem növekedésével ezek az optimalizálások érvényüket vesztették. Egy további "kcryptd_io" sor kerül bevezetésre, hogy leküzdje azt a szűk keresztmetszetet, amely memóriaallokációs várakozást okozott, ha sok kérés érkezett. 2015-ben további rendezési fázist vezettek be, mivel a titkosítási kérések többprocesszoros rendszereken nem szigorúan a beküldési sorrendet tartották be (a lemezhez való hozzáférés nem soros, hanem véletlenszerű volt, és a CFQ ütemező is hatékonytalanul működött). Jelenleg az SSD-meghajtók használatakor a rendezés értelmét veszítette, és a CFQ ütemezőt már nem használják a kernelben.
Figyelembe véve, hogy a modern tárolók gyorsabbak és intelligensebbek lettek, a Linux kernel erőforrás-megosztási rendszere felülvizsgálatra került, és néhány alrendszer átdolgozásra került, Cloudflare mérnökei a dm-crypt új működési módja, amely megszabadítja a felesleges sorok és aszinkron hívások használatától. Ez a mód egy külön "force_inline" jelzővel aktiválható, és a dm-crypt-ot egyszerű proxyvá alakítja, amely titkosítja és visszafejti a beérkező kéréseket. A Crypto API-val való interakciót optimális algoritmusok titkosításának nyílt megválasztásával optimalizálták, amelyek szinkron módban működnek és nem használnak kérdéses sorokat. A Crypto API-val való szinkron működéshez egy modul is rendelkezésre áll, amely lehetővé teszi az FPU/AES-NI használatát a gyorsításra és közvetlenül továbbítja a titkosítási és visszafejtési kéréseket.
Ennek eredményeként a RAM-lemez tesztelése során több mint kétszeresére nőtt a dm-crypt teljesítménye — a teljesítmény 294 MB/s (2 x 147 MB/s) -ről 640 MB/s -ra nőtt, ami nagyon közel áll a nyers titkosítás teljesítményéhez (696 MB/s).
A terheléses tesztelés során a valós szervereken az új megvalósítás teljesítménye nagyon közel állt a titkosítás nélküli konfigurációhoz, és a titkosítás bekapcsolása a Cloudflare gyorsítótáras szervereken nem befolyásolta a válaszidőt. A jövőben a Cloudflare tervezi, hogy átadja a kész javításokat a Linux fő magjába, de előbb át kell dolgozni őket, mivel azok egy bizonyos terheléshez lettek optimalizálva, és nem terjednek ki minden alkalmazási területre, például az alacsony teljesítményű beágyazott eszközök titkosítására.
Forrás: opennet.ru
