AES-NI în OpenSSL sau descărcare în kernel: de care ai nevoie?

Două etichete sunt folosite ca și cum ar fi același lucru: accelerat de hardware și descărcat în kernel. Una descrie ce instrucțiuni execută rutina AES a unei biblioteci, cealaltă descrie unde are loc procesarea pachetelor. Un VPN poate avea prima fără a doua, a doua fără prima sau ambele simultan. Orice decizie despre performanță trebuie să înceapă prin a numi care dintre cele două este schimbată de fapt.

Două axe, nu un singur punctaj

Prima axă este implementarea: codul care face AES-256-GCM este direcționat către o versiune care folosește instrucțiunile dedicate ale procesorului sau către o rutină portabilă care le execută ca aritmetică obișnuită. Această alegere trăiește în interiorul bibliotecii criptografice și se face la inițializarea ei.

A doua axă este plasarea: pachetul trece prin calea de transformare a kernelului sau un demon din spațiul utilizator citește dintr-un dispozitiv de tunel, criptează și scrie înapoi.

Nicio axă nu o limitează pe cealaltă. Un VPN în spațiul utilizator pe un procesor cu instrucțiuni AES le poate folosi tot timpul, iar o cale prin kernel pe un procesor fără ele revine la o implementare software. Etichetele din materialele furnizorilor fac rareori această distincție, și de aceea sfaturile de reglaj copiate între cele două situații atât de des nu fac nimic.

Axa unu: ce cod face criptarea

OpenSSL detectează caracteristicile procesorului în timpul inițializării și folosește rezultatul pentru a alege căi de cod optimizate, așa cum descrie documentația capacităților x86. AES-NI este una dintre capacitățile documentate din spatele acestei direcționări. Nimic din toate acestea nu cere ca biblioteca să devină o componentă a kernelului.

Confirmați că funcția este vizibilă procesului înainte de a presupune că este folosită calea rapidă. Pe Linux sursa este câmpul flags din /proc/cpuinfo, iar într-un invitat reflectă ce expune hipervizorul și nu numele modelului gazdei fizice.

grep -m1 '^flags' /proc/cpuinfo | grep -o '\baes\b'
openssl list -providers -verbose

A doua comandă numește furnizorii încărcați în acea compilare. Nu vă spune ce bibliotecă a legat serviciul VPN, iar o gazdă poate purta două instalări OpenSSL în timp ce procesul care rulează folosește doar una dintre ele.

Axa doi: unde rulează calea pachetelor

Plasarea în kernel înseamnă că transformarea are loc în mecanismul IPsec al kernelului însuși sau într-un driver de tunel din kernel, astfel încât pachetele nu au nevoie de o dus-întors prin procesul din spațiul utilizator pentru fiecare lot. Aceasta poate reduce copiile și schimbările de context și poate distribui munca pe nuclee într-un mod în care un demon cu un singur fir nu poate. De asemenea, mută contoarele și urmele pe care le veți citi când debitul scade, pentru că munca are loc acum de cealaltă parte a unei granițe pe care nu o controlați. Considerați asta un cost de depanare, nu doar o decizie de performanță.

Nu creează suport pentru instrucțiuni, nu configurează un cifru și nu face o rută existentă să funcționeze.

Virtualizarea adaugă o cută și pe această axă. Un invitat poate primi un model de procesor mascat care ascunde caracteristici pe care gazda le are, iar un invitat imbricat poate vedea și mai puțin. Citiți vizualizarea capacităților din interiorul mediului în care VPN-ul rulează cu adevărat, nu din consola hipervizorului.

Ce cumpără fiecare alegere și ce nu poate

Întrebarea practică este unde se duce timpul. Dacă un singur fir ocupat, copii repetate ale tamponului sau un apel de sistem pe pachet limitează debitul, mutarea transformării pe o cale care elimină aceste costuri poate ajuta, cu condiția ca kernelul să implementeze transformarea de care aveți nevoie.

Dacă limita este un uplink congestionat, o cale cu pierderi, un timp dus-întors lung, un serviciu destinație saturat sau un fir fixat pe un nucleu, plasarea nu schimbă nimic important. Același lucru este valabil pentru alegerea instrucțiunilor: AES pe hardware dedicat nu repară o rută lipsă și nu va ajuta dacă tunelul este inactiv pentru că rezolvarea numelor eșuează.

Acolo unde se aplică ambele, se compun. O cale prin kernel poate folosi aceeași direcționare la nivel de instrucțiuni în interiorul API-ului criptografic al kernelului, iar o cale în spațiul utilizator cu o bibliotecă bine aleasă o folosește deja. Decizia nu este care este mai rapidă în abstract, ci pentru ce cost aveți dovezi.

Notați cele patru fapte înainte de a schimba ceva

Notați binarul serviciului și biblioteca criptografică de care este legat, pentru că acestea decid axa unu. Apoi înregistrați protecția datelor negociată, pentru că un cifru fără o cale dedicată de instrucțiuni se comportă diferit de unul care o are, iar suita este aleasă de ambele părți.

Apoi vizualizarea capacităților din interiorul mediului care rulează și, în final, calea activă a pachetelor cu dovezi că modul pe care îl credeți activ este într-adevăr activ. Un modul încărcat nu este dovada că un profil îl folosește, iar o linie de configurare nu este dovada că kernelul a acceptat-o.

Schimbați un singur lucru, apoi comparați cu o încărcare constantă cu aceleași capete și aceeași direcție de transfer. O afirmație despre viteză pe care nu ați măsurat-o valorează mai puțin decât o notă care spune că backendul nu a fost niciodată pus sub semnul întrebării.