AES-NI i OpenSSL eller kjerneoffload: kva treng du?

To etikettar vert brukte som om dei var det same: maskinvareakselerert og kjerneofflast. Den eine skildrar kva instruksjonar AES-rutina i eit bibliotek utfører, den andre skildrar kvar pakkehandsaminga skjer. Ein VPN kan ha den første utan den andre, den andre utan den første eller begge samtidig. Kvar avgjerd om yting må byrje med å nemne kva av dei to du faktisk endrar.

To aksar, ikkje éin poengsum

Den første aksen er implementasjonen: vert koden som gjer AES-256-GCM send til ein versjon som nyttar dei dedikerte instruksjonane til prosessoren, eller til ein flyttbar rutine som utfører dei som vanleg aritmetikk. Det valet bur inne i det kryptografiske biblioteket og vert teke når det initialiserer.

Den andre aksen er plasseringa: går pakken gjennom transformasjonsvegen til kjernen, eller les ein daemon i brukarrommet frå eit tunneleinstrument, krypterer og skriv tilbake.

Ingen av aksane avgrensar den andre. Ein VPN i brukarrommet på ein CPU med AES-instruksjonar kan nytte dei heile tida, og ein kjerneveg på ein CPU utan dei fell tilbake til ein programvareimplementasjon. Etikettene i leverandørmateriell gjer sjeldan den skilnaden, og difor gjer tuningråd som vert kopierte mellom dei to situasjonane så ofte ingenting.

Akse éin: kva kode utfører krypteringa

OpenSSL oppdagar prosessoreigenskapar under initialiseringa og nyttar resultatet til å velje optimaliserte kodevegar, slik dokumentasjonen for x86-eigenskapar skildrar. AES-NI er ein av dei dokumenterte eigenskapane bak denne fordelinga. Ingenting av dette krev at biblioteket vert ein kjernekomponent.

Stadfest at eigenskapen er synleg for prosessen før du reknar med at den snøgge vegen vert nytta. På Linux er kjelda flags-feltet i /proc/cpuinfo, og inne i ein gjest speglar det kva hypervisoren legg fram, ikkje modellnamnet til den fysiske verten.

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

Den andre kommandoen nemner leverandørane som er lasta i den bygginga. Han fortel deg ikkje kva bibliotek VPN-tenesta har lenka mot, og ein vert kan bere to OpenSSL-installasjonar medan prosessen som køyrer berre nyttar éin av dei.

Akse to: kvar pakkevegen køyrer

Plassering i kjernen tyder at transformasjonen skjer i IPsec-maskineriet til kjernen sjølv eller i ein tunneldrivar i kjernen, slik at pakkane ikkje treng ein tur fram og tilbake gjennom ein brukarromsprosess for kvar batch. Det kan kutte kopieringar og kontekstbytte og spreie arbeidet over kjernar på ein måte ein eintråds daemon ikkje kan. Det flyttar òg teljarane og spora du vil lese når gjennomstrøyminga fell, fordi arbeidet no skjer på hi sida av ei grense du ikkje styrer. Sjå på det som ein feilsøkingskostnad, ikkje berre ei ytingsavgjerd.

Det skapar ikkje instruksjonsstøtte, konfigurerer ikkje ein chiffer og får ikkje ein eksisterande rute til å verke.

Virtualisering legg òg ein fold på denne aksen. Ein gjest kan få ein maskert CPU-modell som skjuler eigenskapar verten har, og ein nesta gjest kan sjå endå mindre. Les eigensskapsvisinga innanfrå miljøet der VPN-en faktisk køyrer, ikkje frå hypervisor-konsollen.

Kva kvart val kjøper, og kva det ikkje kan

Det praktiske spørsmålet er kvar tida går. Viss éin travel tråd, gjentekne bufferkopiar eller eit systemkall per pakke avgrensar gjennomstrøyminga, kan det hjelpe å flytte transformasjonen til ein veg som fjernar dei kostnadene, føresett at kjernen implementerer transformasjonen du treng.

Viss grensa er ei overbelasta oppstraumslenkje, ein veg med tap, ein lang rundtur, ei metta teneste på mål eller éin tråd fest til éin kjerne, endrar plasseringa ingenting viktig. Det same gjeld val av instruksjonar: AES på dedikert maskinvare kan ikkje reparere ei manglande rute og hjelper ikkje om tunnelen står ubrukt fordi namneoppslaget feilar.

Der begge gjeld, utfyller dei kvarandre. Ein kjerneveg kan nytte den same fordelinga på instruksjonsnivå inne i krypto-API-et til kjernen, og ein brukarromsveg med eit godt valt bibliotek nyttar ho alt. Avgjerda er ikkje kva som er snøggast i abstrakt forstand; ho er kva kostnad du har prov for.

Skriv ned dei fire fakta før du endrar noko

Skriv ned den binære tenestefila og kryptobiblioteket ho er lenka mot, fordi dei avgjer akse éin. Noter deretter den avtalte databeskyttjinga, fordi ein chiffer utan ein dedikert instruksjonsveg ter seg annleis enn ein med, og settet vert valt av begge partar.

Deretter eigensskapsvisinga innanfrå det køyrande miljøet, og til slutt den aktive pakkevegen med prov for at modusen du trur er aktiv, verkeleg er det. Ein lasta modul er ikkje prov for at ein profil nyttar han, og ei konfigurasjonslinje er ikkje prov for at kjernen har godteke ho.

Endre éin ting, og samanlikn deretter med ei jamn arbeidslast med dei same endepunkta og same overføringsretning. Ei hastigheitspåstand du ikkje har målt, er mindre verd enn eit notat om at backenden aldri var i tvil.