Gli sviluppatori di Cloudflare hanno effettuato lavori per ottimizzare le prestazioni della crittografia dei dischi nel kernel Linux. Di conseguenza sono stati preparati per il sottosistema e Crypto API, che hanno permesso di raddoppiare la larghezza di banda in lettura e scrittura in un test sintetico e di ridurre la latenza di oltre la metà. Nei test su hardware reale, i sovraccarichi dovuti alla crittografia sono stati ridotti praticamente ai livelli osservati con un disco non crittografato.
Cloudflare utilizza dm-crypt per crittografare i dati sui dispositivi utilizzati per il caching dei contenuti nella rete CDN. Dm-crypt opera a livello di dispositivo a blocchi e crittografa le richieste di input/output in scrittura e decripta le richieste in lettura, fungendo da intermediario tra il dispositivo a blocchi e il driver del file system.
Per valutare le prestazioni di dm-crypt, è stato utilizzato il pacchetto per misurare la velocità di lavoro con partizioni crittografate e non crittografate su un disco RAM situato nella RAM per escludere le fluttuazioni delle prestazioni dei dischi e concentrarsi sulle prestazioni del codice. Per le partizioni non crittografate, le prestazioni in lettura e scrittura si attestavano attorno ai 1126 MB/s, ma con la crittografia attivata, la velocità è scesa di 7 volte a 147 MB/s.
Inizialmente si sospettava l'utilizzo di algoritmi inefficaci nel sistema crittografico del kernel. Tuttavia, nei test è stato utilizzato l'algoritmo più veloce aes-xts con una chiave di 256, la cui prestazione, eseguendo il "cryptsetup benchmark", è risultata più di due volte superiore rispetto al risultato testato su disco RAM. Esperimenti con le opzioni di tuning delle prestazioni di dm-crypt non hanno dato risultati: utilizzando l'opzione "—perf-same_cpu_crypt", le prestazioni sono addirittura diminuite a 136 MB/s, mentre specificando l'opzione "—perf-submit_from_crypt_cpus" sono aumentate solo a 166 MB/s.
Un'analisi più approfondita della logica di funzionamento ha rivelato che dm-crypt non è così semplice come appare: al momento della ricezione di una richiesta di scrittura dal driver FS, dm-crypt non la elabora immediatamente, ma la inserisce nella coda "kcryptd", che non viene gestita subito, ma quando si presenta un momento opportuno. Dalla coda, la richiesta viene inviata a Linux Crypto API per l'esecuzione della crittografia. Ma poiché Crypto API utilizza un modello di esecuzione asincrono, la crittografia non avviene immediatamente, ma attraverso un'altra coda. Una volta completata la crittografia, dm-crypt può tentare di ordinare le richieste di scrittura in attesa, utilizzando un albero di ricerca . Alla fine, un thread del kernel raccoglie nuovamente, con un certo ritardo, le richieste di input/output accumulate e le invia allo stack del dispositivo a blocchi.
In lettura, all'inizio dm-crypt aggiunge alla coda "kcryptd_io" la richiesta di recupero dati dal dispositivo. Dopo un certo tempo, i dati diventano disponibili e vengono inseriti nella coda "kcryptd" per la decrittazione.
Kcryptd invia la richiesta a Linux Crypto API, che decrittografa le informazioni in modalità asincrona. Le richieste non sempre passano attraverso tutte le code, ma nel peggior scenario una richiesta di scrittura può rimanere in attesa nelle code fino a 4 volte, mentre una richiesta di lettura fino a 3 volte. Ogni passaggio nella coda provoca ritardi, che sono la causa principale della significativa riduzione delle prestazioni di dm-crypt.
L'uso delle code è motivato dalla necessità di operare in condizioni di interruzione. Nel 2005, quando è stato implementato il modello di funzionamento attuale di dm-crypt basato sulle code, Crypto API non era ancora asincrono. Dopo la transizione di Crypto API a un modello di esecuzione asincrono, è stata applicata sostanzialmente una doppia protezione. Le code sono state inoltre introdotte per risparmiare sul consumo dello stack del kernel, ma dopo l'aumento di questo nel 2014, queste ottimizzazioni hanno perso di attualità. Una coda aggiuntiva "kcryptd_io" è stata introdotta per superare il collo di bottiglia che portava a un'attesa per l'allocazione di memoria in presenza di molte richieste. Nel 2015 è stata introdotta anche una fase di ordinamento poiché le richieste di crittografia nei sistemi multicore potevano completarsi senza rispettare l'ordine di invio (invece di un accesso sequenziale al disco, si accedeva in modo casuale, e il pianificatore CFQ non funzionava in modo efficace). Attualmente, con l'uso di SSD, l'ordinamento ha perso di significato e il pianificatore CFQ non viene più utilizzato nel kernel.
Considerando che i dispositivi moderni sono diventati più veloci e intelligenti, il sistema di distribuzione delle risorse nel kernel Linux è stato rivisto e alcune sottosistemi sono stati riprogettati, gli ingegneri di Cloudflare in dm-crypt è stata introdotta una nuova modalità operativa, priva dell'uso di code e chiamate asincrone. Questa modalità viene attivata con un flag separato "force_inline" e trasforma dm-crypt in un semplice proxy che cifra e decifra le richieste in ingresso. L'interazione con l'API Crypto è stata ottimizzata attraverso la selezione esplicita di algoritmi di cifratura che operano in modalità sincrona e non utilizzano code di richieste. Per un funzionamento sincrono con l'API Crypto è stato un modulo che consente di utilizzare FPU/AES-NI per accélérer e instradare direttamente le richieste di cifratura e decifratura.
Di conseguenza, durante il test con il disco RAM, si è riusciti a più che raddoppiare le prestazioni di dm-crypt: le prestazioni sono aumentate da 294 MB/s (2 x 147 MB/s) a 640 MB/s, molto vicino alle prestazioni della cifratura pura (696 MB/s).
Durante il test del carico su server reali, la nuova implementazione ha mostrato prestazioni molto vicine a quelle di una configurazione senza cifratura, e l'attivazione della cifratura sui server con caching Cloudflare non ha avuto alcun impatto sui tempi di risposta. In futuro, Cloudflare prevede di integrare le patch preparate nel nucleo principale di Linux, ma prima sarà necessario rielaborarle, poiché sono ottimizzate per specifici carichi di lavoro e non coprono tutte le aree di applicazione, come la cifratura su dispositivi embedded a bassa potenza.
Fonte: opennet.ru
