AES-NI i OpenSSL eller kjerneoffload: hva trenger du egentlig?

To merkelapper brukes som om de betyr det samme: maskinvareakselerert og kjerneoffloadet. Den ene sier hvilke instruksjoner en AES-rutine i et bibliotek utfører, den andre sier hvor pakkebehandlingen foregår. En VPN kan ha den første uten den andre, den andre uten den første, eller begge på samme tid. All vurdering av ytelse må begynne med å navngi hvilken av de to du faktisk endrer.

To akser, ikke én karakter

Den første aksen er implementasjonen: blir koden som utfører AES-256-GCM sendt til en variant som bruker prosessorens egne instruksjoner, eller til en flyttbar rutine som kjører dem som vanlig aritmetikk. Dette valget ligger inne i kryptobiblioteket og tas når det initialiseres.

Den andre aksen er plasseringen: går pakken gjennom transformasjonsveien i kjernen, eller leser en daemon i brukerland fra en tunnelenhet, krypterer og skriver tilbake.

Aksene begrenser ikke hverandre. En VPN i brukerland på en prosessor med AES-instruksjoner kan bruke dem hele tiden, og en kjernevei på en prosessor uten dem faller tilbake på en programvareimplementasjon. Merkelappene i leverandørmateriell gjør sjelden dette skillet, og derfor virker justeringstips som kopieres mellom de to situasjonene så ofte ikke i det hele tatt.

Akse én: hvilken kode som utfører krypteringen

OpenSSL oppdager prosessoregenskaper ved oppstart og bruker resultatet til å velge optimaliserte kodeveier, slik dokumentasjonen for x86-egenskaper forklarer. AES-NI er én av de dokumenterte egenskapene bak denne fordelingen. Ingenting av dette krever at biblioteket blir en del av kjernen.

Kontroller at egenskapen er synlig for prosessen før du tar for gitt at den raske veien brukes. På Linux er kilden flags-feltet i /proc/cpuinfo, og inne i en gjest gjenspeiler det hypervisorens eksponering og ikke det fysiske vertsmaskinens modellnavn.

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

Den andre kommandoen lister leverandørene som er lastet i den byggingen. Den sier ikke hvilket bibliotek VPN-tjenesten er lenket mot, og en vert kan ha to OpenSSL-installasjoner mens den kjørende prosessen bare bruker én.

Akse to: hvor pakkeveien løper

Plassering i kjernen betyr at transformasjonen skjer i kjernens egen IPsec-maskin eller i en tunneldriver inne i kjernen, slik at pakkene slipper en tur frem og tilbake gjennom en brukerprosess for hver gruppe. Det kan spare kopieringer og kontekstbytter og fordele arbeidet over kjerner på en måte en entrådet daemon ikke makter. Det flytter også tellerne og sporene du leser når gjennomstrømningen faller, fordi arbeidet nå skjer på den andre siden av en grense du ikke råder over. Se på det som en feilsøkingskostnad, ikke bare et ytelsesvalg.

Det gir ikke instruksjonsstøtte, setter ikke opp en chiffer og får ikke en eksisterende rute til å fungere.

Virtualisering legger også en brett på denne aksen. En gjest kan få en maskert prosessormodell som skjuler egenskaper verten har, og en nestet gjest kan se enda mindre. Les egenskapsoversikten inne fra miljøet der VPN-en faktisk kjører, ikke fra hypervisorkonsollen.

Hva hvert valg gir, og hva det ikke kan

Det praktiske spørsmålet er hvor tiden tar veien. Hvis én opptatt tråd, gjentatte bufferkopier eller et systemkall per pakke begrenser gjennomstrømningen, kan det hjelpe å flytte transformasjonen til en vei som fjerner disse kostnadene, forutsatt at kjernen har den transformasjonen du trenger.

Hvis grensen er en overbelastet oppstrømslinje, en vei med tap, en lang rundtur, en mettet mottakertjeneste eller én tråd låst til én kjerne, endrer plasseringen ingenting vesentlig. Det samme gjelder valget av instruksjoner: AES på dedikert maskinvare reparerer ikke en manglende rute og hjelper ikke hvis tunnelen står ubrukt fordi navneoppslag feiler.

Der begge gjelder, spiller de sammen. En kjernevei kan bruke den samme instruksjonsnivå-fordelingen inne i kjernens krypto-API, og en brukerlandsvei med et velvalgt bibliotek bruker den allerede. Valget står ikke mellom hva som er raskest i det abstrakte, men hvilken kostnad du har bevis for.

Skriv ned de fire fakta før du endrer noe

Skriv ned tjenestens binærfiler og kryptobiblioteket den er lenket mot, fordi de avgjør akse én. Deretter noterer du den forhandlede databeskyttelsen, fordi en chiffer uten en egen instruksjonsvei oppfører seg annerledes enn en som har det, og settet velges av begge sider.

Så egenskapsoversikten inne fra det kjørende miljøet, og til slutt den aktive pakkeveien med bevis for at modusen du tror er slått på, virkelig er det. En lastet modul er ikke bevis for at en profil bruker den, og en konfigurasjonslinje er ikke bevis for at kjernen godtok den.

Endre én ting, og sammenlign så med en jevn arbeidsmengde med de samme endepunktene og samme overføringsretning. En hastighetspåstand du ikke har målt, er mindre verdt enn et notat om at backenden aldri var omstridt.