AES-NI yn OpenSSL of kernel-offload: hokker hawwe jo nedich?

Twa labels wurde brûkt as wiene se itselde: hardware-fersnelle en kernel-offload. It iene beskriuwt hokker ynstruksjes de AES-routine fan in bibleteek útfiert, it oare beskriuwt wêr’t de pakketferwurking plakfynt. In VPN kin it earste sûnder it twadde hawwe, it twadde sûnder it earste, of beide tagelyk. Eltse beslissing oer prestaasjes moat begjinne mei it neamen fan hokker fan de beide jo echt feroarje.

Twa assen, net ien sifer

De earste as is de ymplemintaasje: wurdt de koade dy’t AES-256-GCM docht nei in ferzje stjoerd dy’t de taweide ynstruksjes fan de prosessor brûkt, of nei in draachbere routine dy’t se as gewoane rekkenkunde útfiert. Dy kar wennet yn’e kryptografyske bibleteek en wurdt makke as dy inisjaliseart.

De twadde as is de pleatsing: giet it pakket troch it transformaasjepaad fan de kernel, of lêst in daemon yn’e brûkersromte fan in tunnelapparaat, fersiferet en skriuwt werom.

Gjin as beheint de oare. In VPN yn’e brûkersromte op in prosessor mei AES-ynstruksjes kin se de hiele tiid brûke, en in kernelpaad op in prosessor sûnder dy falt werom op in software-ymplemintaasje. De labels yn materiaal fan leveransiers meitsje dat ûnderskied selden, en dêrom dogge ôfstimtips dy’t tusken de beide situaasjes kopiearre wurde sa faak neat.

As ien: hokker koade docht de fersifering

OpenSSL detektearret prosessoreigenskippen by de inisjalisaasje en brûkt it resultaat om optimisearre kodepaden te kiezen, sa’t de dokumintaasje oer x86-mooglikheden beskriuwt. AES-NI is ien fan’e dokumintearre mooglikheden efter dy stjoering. Neat hjirfan freget dat de bibleteek in kernelkomponint wurdt.

Befêstigje dat de eigenskip foar it proses sichtber is foar’t jo oannimme dat it rappe paad brûkt wurdt. Op Linux is de boarne it flags-fjild yn /proc/cpuinfo, en binnen in gast wjerspegelet it wat de hypervisor bleatleit en net de modelnamme fan’e fysike host.

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

It twadde kommando neamt de providers dy’t yn dy build laden binne. It fertelt jo net hokker bibleteek de VPN-tsjinst keppele hat, en in host kin twa OpenSSL-ynstallaasjes drage wylst it rinnende proses mar ien fan beide brûkt.

As twa: wêr’t it pakketpaad rint

Pleatsing yn’e kernel betsjut dat de transformaasje yn’e IPsec-masjinerie fan’e kernel sels of yn in tunnelstjoerder yn’e kernel bart, sadat pakketten foar elke bondel gjin hin-en-wer reis troch in proses yn’e brûkersromte nedich hawwe. Dat kin kopyen en kontekstwikselingen besparje en it wurk oer kearnen ferspriede op in manier dy’t in iendriedsdaemon net kin. It ferpleatst ek de tellers en spoaren dy’t jo lêze sille as de trochfier sakket, om’t it wurk no oan’e oare kant fan in grins bart dy’t jo net behearskje. Sjoch dat as in debugkosten, net allinnich as in prestaasjebeslissing.

It makket gjin ynstruksjestipe, konfigurearret gjin sipers en krijt in besteand paad net oan’t wurkjen.

Virtualisaasje foeget ek in ploaits ta op dizze as. In gast kin in maskearre prosessormodel krije dat eigenskippen ferberget dy’t de host hat, en in nêste gast kin noch minder sjen. Lês de mooglikheidsfinster fan binnen it omjouwing wêr’t de VPN echt rint, net fan’e hypervisor-konsole.

Wat elk kar keapet, en wat it net kin

De praktyske fraach is wêr’t de tiid hinne giet. As ien beset draad, werhelle bufferkopyen of in systeemoprop per pakket de trochfier beheine, kin it ferpleatsen fan’e transformaasje nei in paad dat dy kosten fuorthellet helpe, mits de kernel de transformaasje ymplemintearret dy’t jo nedich hawwe.

As de beheining in oerbefolle uplink, in paad mei ferlies, in lange hin-en-wer tiid, in fersadige bestimmingstsjinst of ien draad oan ien kearn fêst is, feroaret pleatsing neat dat fan belang is. Itselde jildt foar de kar fan ynstruksjes: AES op taweide hardware kin in ûntbrekkend paad net reparearje en sil net helpe as de tunnel stil is om’t namme-oplossing mislearret.

Wêr’t beide jilde, wurde se kombinearre. In kernelpaad kin deselde stjoering op ynstruksjenivo yn’e krypto-API fan’e kernel brûke, en in brûkersromtepaad mei in goed keazen bibleteek brûkt it al. De beslissing is net hokker yn it abstrakte rapper is; it is foar hokker kosten jo bewiis hawwe.

Skriuw de fjouwer feiten op foar’t jo wat feroarje

Skriuw de tsjinstbinary en de kryptobibleteek dêr’t er oan keppele is op, om’t dy as ien beslisse. Skriuw dêrnei de úthannele databeskerming op, om’t in sipers sûnder taweide ynstruksjepaad him oars hâldt en draacht as ien mei, en de set wurdt troch beide partijen keazen.

Dêrnei de mooglikheidsfinster fan binnen it rinnende omjouwing, en as lêste it aktive pakketpaad mei bewiis dat de modus dy’t jo tinke dat oan is, dat echt is. In laden module is gjin bewiis dat in profyl him brûkt, en in konfiguraasjeline is gjin bewiis dat de kernel dy akseptearre hat.

Feroarje ien ding en fergelykje dan mei in konsekwinte wurklêst mei deselde einpunten en deselde rjochting fan oerdracht. In sneldheidsbewearing dy’t jo net metten hawwe is minder wurdich as in notysje dat de backend nea yn twifel wie.