AES-NI in OpenSSL teenoor kernel-oorlaai: watter een het jy nodig?

Twee etikette word gebruik asof hulle dieselfde ding is: hardeware-versnel en kernel-afgelaai. Die een beskryf watter instruksies ’n biblioteek se AES-roetine uitvoer, en die ander beskryf waar pakketverwerking plaasvind. ’n VPN kan die eerste sonder die tweede hê, die tweede sonder die eerste, of albei gelyk. Enigiets wat jy oor werkverrigting besluit, moet begin deur te noem watter van die twee jy werklik verander.

Twee asse, nie een telling nie

Die eerste as is implementering: dispatseer die kode wat AES-256-GCM doen na ’n weergawe wat die verwerker se toegewyde instruksies gebruik, of na ’n draagbare roetine wat hulle as gewone rekenkunde uitvoer. Daardie keuse woon binne die kriptografiese biblioteek en word gemaak wanneer dit initialiseer.

Die tweede as is plasing: beweeg die pakket deur die kernel se transformasiepad, of lees ’n gebruikersruimte-daemon van ’n tonneltoestel, versleutel en skryf terug uit.

Nie een as beperk die ander nie. ’n Gebruikersruimte-VPN op ’n verwerker met AES-instruksies kan hulle die hele tyd gebruik, en ’n kernelpad op ’n verwerker sonder hulle val terug op ’n sagteware-implementering. Die etikette in verskaffersmateriaal maak selde daardie onderskeid, en daarom doen insteladvies wat tussen die twee situasies gekopieer word so dikwels niks.

As een: watter kode voer die versleuteling uit

OpenSSL bespeur verwerkerkenmerke tydens initialisering en gebruik die resultaat om geoptimaliseerde kodepaaie te kies, soos die x86-vermoë-dokumentasie beskryf. AES-NI is een van die gedokumenteerde vermoëns agter daardie versending. Niks hiervan vereis dat die biblioteek ’n kernelkomponent word nie.

Bevestig dat die kenmerk vir die proses sigbaar is voordat jy aanneem die vinnige pad word gevolg. Op Linux is die flags-veld van /proc/cpuinfo die bron, en binne ’n gas weerspieël dit wat die hipersigbare blootlê eerder as die fisiese gasheer se modelnaam.

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

Die tweede opdrag noem die verskaffers wat in daardie bou gelaai is. Dit sê nie vir jou watter biblioteek die VPN-diens gekoppel het nie, en ’n gasheer kan twee OpenSSL-installasies dra terwyl die lopende proses net een daarvan gebruik.

As twee: waar die pakketpad loop

Kernelplasing beteken die transformasie vind in die kernel se eie IPsec-masjinerie of binne ’n in-kernel tonnelaandrywer plaas, sodat pakkette nie vir elke bondel ’n heen-en-weer reis deur ’n gebruikersruimteproses nodig het nie. Dit kan kopieë en konteksskakelaars verminder, en dit kan werk oor kerne versprei op maniere wat ’n enkelvoudige draad-daemon nie kan nie. Dit verskuif ook die tellers en spore wat jy sal lees wanneer deurvoer daal, want die werk gebeur nou aan die ander kant van ’n grens wat jy nie beheer nie. Beskou dit as ’n ontfoutkoste, nie net ’n werkverrigtingsbesluit nie.

Dit skep nie instruksieondersteuning nie, konfigureer nie ’n syfer nie, en maak nie ’n bestaande roete werk nie.

Virtualisering voeg ook ’n plooi op hierdie as by. ’n Gas kan ’n gemaskeerde verwerker-model kry wat kenmerke wegsteek wat die gasheer het, en ’n geneste gas kan weer minder sien. Lees die vermoë-aansig van binne die omgewing waar die VPN werklik loop, nie van die hipersigbare-konsole nie.

Wat elke keuse koop, en wat dit nie kan nie

Die praktiese vraag is waar die tyd heen gaan. As ’n enkele besige draad, herhaalde buffer-kopieë of ’n per-pakket stelseloproep-patroon deurvoer beperk, kan die verskuiwing van die transformasie na ’n pad wat daardie koste verwyder help, mits die kernel die transformasie implementeer wat jy nodig het.

As die beperking ’n oorlaaide opstuurverbinding, ’n verliesryke pad, ’n lang heen-en-weer tyd, ’n versadigde bestemmingsdiens of een draad wat aan een kern vasgepen is is, verander plasing niks wat saak maak nie. Dieselfde geld vir instruksiekeuse: AES op toegewyde hardeware kan nie ’n ontbrekende roete herstel nie, en dit sal nie help as die tonnel ledig is omdat naamoplossing faal nie.

Waar albei van toepassing is, komponeer hulle. ’n Kernelpad kan dieselfde instruksievlak-versending binne die kernel se kripto-API gebruik, en ’n gebruikersruimtepad met ’n goed gekose biblioteek gebruik dit reeds. Die besluit is nie watter een in die abstrak vinniger is nie; dit is vir watter koste jy bewyse het.

Teken die vier feite aan voordat jy iets verander

Skryf die diensbinêre en die kriptobiblioteek wat dit koppel neer, want dié bepaal as een. Teken dan die onderhandelde databeskerming aan, want ’n syfer sonder ’n toegewyde instruksiepad gedra hom anders as een met, en die pakket word deur albei eweknieë gekies.

Volgende, die vermoë-aansig van binne die lopende omgewing, en laastens die aktiewe pakketpad met bewyse dat die modus wat jy dink geaktiveer is, werklik is. ’n Gelaaide module is nie bewys dat ’n profiel dit gebruik nie, en ’n konfigurasie-reël is nie bewys dat die kernel dit aanvaar het nie.

Verander een ding, vergelyk dan teen ’n konsekwente werklading met dieselfde eindpunte en dieselfde rigting van oordrag. ’n Spoedbewering wat jy nie gemeet het nie, is minder werd as ’n nota wat sê die agterkant was nooit in twyfel nie.