Mga developer mula sa Cloudflare tungkol sa pagsasagawa ng trabaho upang ma-optimize ang pagganap ng disk encryption sa Linux kernel. Dahil dito, naghanda sila para sa subsystem at Crypto API, na naging posible upang higit sa doble ang read at write throughput sa synthetic na pagsubok, pati na rin ang paghati sa latency. Kapag sinubukan sa totoong hardware, ang overhead ng pag-encrypt ay nabawasan sa halos antas na naobserbahan kapag nagtatrabaho sa isang disk na walang pag-encrypt ng data.
Gumagamit ang Cloudflare ng dm-crypt para i-encrypt ang data sa mga storage device na ginagamit para mag-cache ng content sa CDN. Gumagana ang Dm-crypt sa antas ng block device at nag-e-encrypt ng write I/O request at nagde-decrypt ng read request, na kumikilos bilang isang layer sa pagitan ng block device at ng file system driver.
Upang suriin ang pagganap ng dm-crypt gamit ang package Sinukat namin ang bilis ng pagtatrabaho sa mga naka-encrypt at hindi naka-encrypt na mga partisyon sa isang RAM disk na matatagpuan sa RAM upang alisin ang mga pagbabago sa pagganap ng disk at tumuon sa pagganap ng code. Para sa mga hindi naka-encrypt na partisyon, nanatili sa 1126 MB/s ang pagganap sa pagbasa at pagsulat, ngunit bumaba ang bilis kapag pinagana ang pag-encrypt 7 sa oras at umabot sa 147 MB/s.
Sa una, lumitaw ang hinala tungkol sa paggamit ng mga hindi mahusay na algorithm sa kernel cryptosystem. Ngunit ginamit ng mga pagsubok ang pinakamabilis na algorithm, aes-xts, na may 256 encryption key, na ang pagganap kapag nagpapatakbo ng "cryptsetup benchmark" ay higit sa dalawang beses na mas mataas kaysa sa resulta na nakuha kapag sinusubukan ang isang RAM disk. Ang mga eksperimento sa mga dm-crypt flag para sa pag-tune ng performance ay hindi nagbunga ng mga resulta: kapag ginagamit ang flag na β--perf-same_cpu_crypt,β bumaba pa ang performance sa 136 MB/s, at kapag tinukoy ang flag na β--perf-submit_from_crypt_cpusβ tumaas lang hanggang 166 MB/s.
Ang isang mas malalim na pagsusuri ng operating logic ay nagpakita na ang dm-crypt ay hindi kasing simple ng tila - kapag ang isang kahilingan sa pagsulat ay dumating mula sa driver ng FS, ang dm-crypt ay hindi agad na pinoproseso, ngunit inilalagay ito sa "kcryptd" na pila, na kung saan ay hindi na-parse kaagad, ngunit kapag maginhawang sandali. Mula sa queue, ipinapadala ang kahilingan sa Linux Crypto API upang magsagawa ng pag-encrypt. Ngunit dahil ang Crypto API ay gumagamit ng isang asynchronous na modelo ng pagpapatupad, ang pag-encrypt ay hindi rin ginagawa kaagad, ngunit nilalampasan ang isa pang pila. Pagkatapos makumpleto ang pag-encrypt, maaaring subukan ng dm-crypt na pagbukud-bukurin ang mga nakabinbing kahilingan sa pagsulat gamit ang isang puno ng paghahanap . Sa dulo, ang isang hiwalay na kernel thread muli, na may isang tiyak na pagkaantala, ay kukuha ng mga naipong kahilingan sa I/O at ipinapadala ang mga ito sa block device stack.
Kapag nagbabasa, nagdaragdag muna ng kahilingan ang dm-crypt sa queue ng βkcryptd_ioβ para makatanggap ng data mula sa drive. Pagkaraan ng ilang oras, magiging available ang data at inilalagay sa queue ng "kcryptd" para sa pag-decryption.
Nagpapadala ang Kcryptd ng kahilingan sa Linux Crypto API, na nagde-decrypt ng impormasyon nang asynchronous. Ang mga kahilingan ay hindi palaging dumadaan sa lahat ng mga pila, ngunit sa pinakamasamang sitwasyon, ang isang kahilingan sa pagsulat ay nagtatapos sa mga pila ng hanggang 4 na beses, at isang kahilingan sa pagbabasa hanggang sa 3 beses. Ang bawat hit sa queue ay nagdudulot ng mga pagkaantala, na siyang pangunahing dahilan ng makabuluhang pagbaba sa pagganap ng dm-crypt.
Ang paggamit ng mga pila ay dahil sa pangangailangang magtrabaho sa mga kondisyon kung saan may mga pagkaantala. Noong 2005, nang ang kasalukuyang modelo ng pagpapatakbo na nakabatay sa queue ng dm-crypt ay ipinatupad, ang Crypto API ay hindi pa asynchronous. Matapos mailipat ang Crypto API sa isang asynchronous na modelo ng pagpapatupad, mahalagang dobleng proteksyon ang nagsimulang gamitin. Ang mga pila ay ipinakilala din upang makatipid sa pagkonsumo ng kernel stack, ngunit pagkatapos ng pagtaas nito noong 2014, ang mga pag-optimize na ito ay nawala ang kanilang kaugnayan. Ang isang karagdagang queue na "kcryptd_io" ay ipinakilala upang malampasan ang bottleneck na nagreresulta sa paghihintay para sa paglalaan ng memory kapag dumating ang isang malaking bilang ng mga kahilingan. Noong 2015, isang karagdagang yugto ng pag-uuri ang ipinakilala, dahil ang mga kahilingan sa pag-encrypt sa mga sistema ng multiprocessor ay maaaring makumpleto nang wala sa order (sa halip na sunud-sunod na pag-access sa disk, ang pag-access ay isinasagawa sa isang random na pagkakasunud-sunod, at ang CFQ scheduler ay hindi gumana nang mahusay). Sa kasalukuyan, kapag gumagamit ng mga SSD drive, ang pag-uuri ay nawala ang kahulugan nito, at ang CFQ scheduler ay hindi na ginagamit sa kernel.
Isinasaalang-alang na ang mga modernong drive ay naging mas mabilis at mas matalino, ang sistema ng pamamahagi ng mapagkukunan sa Linux kernel ay binago at ang ilang mga subsystem ay muling idinisenyo, ang mga inhinyero ng Cloudflare Ang dm-crypt ay may bagong operating mode na nag-aalis ng paggamit ng mga hindi kinakailangang pila at mga asynchronous na tawag. Ang mode ay pinagana ng isang hiwalay na flag na "force_inline" at dinadala ang dm-crypt sa anyo ng isang simpleng proxy na nag-e-encrypt at nagde-decrypt ng mga papasok na kahilingan. Ang pakikipag-ugnayan sa Crypto API ay na-optimize sa pamamagitan ng tahasang pagpili ng mga algorithm ng pag-encrypt na gumagana sa synchronous mode at hindi gumagamit ng mga queue ng kahilingan. Upang gumana nang sabay-sabay sa Crypto API nagkaroon isang module na nagbibigay-daan sa iyong gamitin ang FPU/AES-NI para sa acceleration at direktang nagpapasa ng mga kahilingan sa pag-encrypt at pag-decryption.
Bilang resulta, kapag sinusubukan ang isang RAM disk, posible na higit sa doble ang pagganap ng dm-crypt - tumaas ang pagganap mula 294 MB/s (2 x 147 MB/s) hanggang 640 MB/s, na napakalapit sa ang pagganap ng hubad na pag-encrypt (696 MB / s).
Kapag sinusubukan ang pag-load sa mga tunay na server, ang bagong pagpapatupad ay nagpakita ng pagganap na napakalapit sa configuration na tumatakbo nang walang pag-encrypt, at ang pagpapagana ng pag-encrypt sa mga server na may Cloudflare cache ay walang epekto sa bilis ng pagtugon. Sa hinaharap, plano ng Cloudflare na ilipat ang mga inihandang patch sa pangunahing kernel ng Linux, ngunit bago iyon kailangan nilang muling gawin, dahil ang mga ito ay na-optimize para sa isang tiyak na pagkarga at hindi sumasaklaw sa lahat ng mga lugar ng aplikasyon, halimbawa, pag-encrypt sa mababang -power embedded device.
Pinagmulan: opennet.ru