AES-NI në OpenSSL apo shkarkim në kernel: cila ju duhet?

Dy etiketa përdoren sikur të ishin e njëjta gjë: e përshpejtuar nga hardueri dhe e transferuar në kernel. E para përshkruan cilat udhëzime ekzekuton rutina AES e një biblioteke, e dyta përshkruan ku ndodh përpunimi i paketave. Një VPN mund të ketë të parën pa të dytën, të dytën pa të parën ose të dyja njëkohësisht. Çdo vendim për performancën duhet të fillojë duke emërtuar cilën nga të dyja po ndryshoni në të vërtetë.

Dy akse, jo një rezultat

Aksi i parë është zbatimi: kodi që bën AES-256-GCM drejtohet te një version që përdor udhëzimet e dedikuara të procesorit apo te një rutinë e transportueshme që i ekzekuton ato si aritmetikë e zakonshme. Kjo zgjedhje jeton brenda bibliotekës kriptografike dhe merret kur ajo inicializohet.

Aksi i dytë është vendosja: paketa kalon nëpër rrugën e transformimit të kernelit apo një demon në hapësirën e përdoruesit lexon nga një pajisje tuneli, kripton dhe shkruan mbrapsht.

Asnjë aks nuk e kufizon tjetrin. Një VPN në hapësirën e përdoruesit në një CPU me udhëzime AES mund t’i përdorë ato gjatë gjithë kohës, dhe një rrugë në kernel në një CPU pa ato kthehet te një zbatim softuerik. Etiketat në materialet e furnitorëve rrallë e bëjnë këtë dallim, dhe për këtë arsye këshillat e rregullimit të kopjuara midis dy situatave kaq shpesh nuk bëjnë asgjë.

Aksi i parë: cili kod bën kriptimin

OpenSSL zbulon veçoritë e procesorit gjatë inicializimit dhe përdor rezultatin për të zgjedhur rrugë kodi të optimizuara, siç përshkruan dokumentacioni i aftësive x86. AES-NI është një nga aftësitë e dokumentuara pas këtij drejtimi. Asgjë nga kjo nuk kërkon që biblioteka të bëhet komponent i kernelit.

Konfirmoni që veçoria është e dukshme për procesin përpara se të supozoni që përdoret rruga e shpejtë. Në Linux burimi është fusha flags në /proc/cpuinfo, dhe brenda një mysafiri pasqyron atë që ekspozon hipervizori dhe jo emrin e modelit të hostit fizik.

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

Komanda e dytë emërton ofruesit e ngarkuar në atë ndërtim. Nuk ju tregon se cilën bibliotekë ka lidhur shërbimi VPN, dhe një host mund të mbajë dy instalime OpenSSL ndërsa procesi që punon përdor vetëm njërin prej tyre.

Aksi i dytë: ku punon rruga e paketave

Vendosja në kernel do të thotë që transformimi ndodh në mekanizmin IPsec të vetë kernelit ose brenda një drejtuesi tuneli në kernel, kështu që paketat nuk kanë nevojë për një udhëtim vajtje-ardhje nëpër një proces në hapësirën e përdoruesit për çdo grup. Kjo mund të presë kopjimet dhe ndërrimet e kontekstit dhe ta shpërndajë punën nëpër bërthama në një mënyrë që një demon me një fije nuk mundet. Gjithashtu i zhvendos numëruesit dhe gjurmët që do të lexoni kur xhiroja bie, sepse puna tani ndodh në anën tjetër të një kufiri që nuk e kontrolloni. Konsiderojeni atë si kosto e korrigjimit të gabimeve, jo vetëm si vendim performance.

Nuk krijon mbështetje udhëzimesh, nuk konfiguron një shifër dhe nuk e bën funksionale një rrugë ekzistuese.

Virtualizimi shton një palosje edhe në këtë aks. Një mysafiri mund t’i jepet një model CPU i maskuar që fsheh veçori që hosti ka, dhe një mysafir i ndërlidhur mund të shohë edhe më pak. Lexoni pamjen e aftësive nga brenda mjedisit ku VPN punon vërtet, jo nga konsola e hipervizorit.

Çfarë blen çdo zgjedhje, dhe çfarë nuk mundet

Pyetja praktike është ku shkon koha. Nëse një fije e zënë, kopjime të përsëritura buferi ose një thirrje sistemi për paketë kufizojnë xhiron, zhvendosja e transformimit në një rrugë që i heq ato kosto mund të ndihmojë, me kusht që kerneli të zbatojë transformimin që ju nevojitet.

Nëse kufiri është një lidhje dalëse e mbingarkuar, një rrugë me humbje, një kohë e gjatë vajtje-ardhje, një shërbim destinacioni i ngopur ose një fije e gozhduar në një bërthamë, vendosja nuk ndryshon asgjë të rëndësishme. E njëjta gjë vlen për zgjedhjen e udhëzimeve: AES në harduer të dedikuar nuk riparon një rrugë që mungon dhe nuk do të ndihmojë nëse tuneli është i papunë sepse zgjidhja e emrave dështon.

Aty ku vlejnë të dyja, ato kombinohen. Një rrugë në kernel mund të përdorë të njëjtin drejtim në nivel udhëzimesh brenda API-së kriptografike të kernelit, dhe një rrugë në hapësirën e përdoruesit me një bibliotekë të zgjedhur mirë tashmë e përdor atë. Vendimi nuk është cila është më e shpejtë në mënyrë abstrakte; është për cilën kosto keni prova.

Shkruani katër faktet përpara se të ndryshoni diçka

Shkruani binarin e shërbimit dhe bibliotekën kriptografike me të cilën është lidhur, sepse ato vendosin aksin e parë. Më pas regjistroni mbrojtjen e të dhënave të negociuar, sepse një shifër pa rrugë të dedikuar udhëzimesh sillet ndryshe nga një me të, dhe grupin e zgjedhin të dy palët.

Më pas, pamja e aftësive nga brenda mjedisit që punon dhe së fundi rruga aktive e paketave me provë që modaliteti që mendoni se është aktiv është vërtet i tillë. Një modul i ngarkuar nuk është provë që një profil e përdor atë, dhe një rresht konfigurimi nuk është provë që kerneli e ka pranuar.

Ndryshoni një gjë, më pas krahasoni me një ngarkesë pune të njëtrajtshme me të njëjtat pika fundore dhe të njëjtin drejtim transferimi. Një pohim shpejtësie që nuk e keni matur vlen më pak se një shënim që thotë se backend-i nuk ka qenë kurrë në dyshim.