AES-NI in OpenSSL of kernel-offload: welke heeft u nodig?

Twee labels worden gebruikt alsof ze hetzelfde zijn: hardwareversneld en naar de kernel overgeheveld. Het ene beschrijft welke instructies de AES-routine van een bibliotheek uitvoert, het andere beschrijft waar de pakketverwerking plaatsvindt. Een VPN kan het eerste hebben zonder het tweede, het tweede zonder het eerste, of beide tegelijk. Elke beslissing over prestaties moet beginnen met benoemen welke van de twee u werkelijk verandert.

Twee assen, niet één score

De eerste as is de implementatie: wordt de code die AES-256-GCM doet gestuurd naar een versie die de toegewijde instructies van de processor gebruikt, of naar een draagbare routine die ze als gewone rekenkunde uitvoert. Die keuze woont in de cryptografische bibliotheek en wordt gemaakt wanneer die initialiseert.

De tweede as is de plaatsing: gaat het pakket door het transformatiepad van de kernel, of leest een daemon in de gebruikersruimte van een tunnelapparaat, versleutelt en schrijft terug.

Geen van de assen beperkt de andere. Een VPN in de gebruikersruimte op een CPU met AES-instructies kan ze de hele tijd gebruiken, en een kernelpad op een CPU zonder die instructies valt terug op een software-implementatie. De labels in leveranciersmateriaal maken dat onderscheid zelden, en daarom doen tuningadviezen die tussen de twee situaties worden gekopieerd zo vaak niets.

As één: welke code doet de versleuteling

OpenSSL detecteert processorkenmerken tijdens de initialisatie en gebruikt het resultaat om geoptimaliseerde codepaden te kiezen, zoals de documentatie over x86-mogelijkheden beschrijft. AES-NI is een van de gedocumenteerde mogelijkheden achter die verdeling. Niets hiervan vereist dat de bibliotheek een kernelcomponent wordt.

Bevestig dat het kenmerk zichtbaar is voor het proces voordat u aanneemt dat het snelle pad wordt gebruikt. Op Linux is de bron het veld flags in /proc/cpuinfo, en binnen een gast weerspiegelt het wat de hypervisor blootlegt en niet de modelnaam van de fysieke host.

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

De tweede opdracht noemt de providers die in die build zijn geladen. Ze vertelt u niet welke bibliotheek de VPN-dienst heeft gelinkt, en één host kan twee OpenSSL-installaties dragen terwijl het draaiende proces er slechts één gebruikt.

As twee: waar het pakketpad loopt

Plaatsing in de kernel betekent dat de transformatie plaatsvindt in de eigen IPsec-machinerie van de kernel of in een tunneldriver in de kernel, zodat pakketten voor elke batch geen heen-en-terugreis door een proces in de gebruikersruimte nodig hebben. Dat kan kopieën en contextwisselingen schelen en het werk over cores verdelen op een manier die een single-thread daemon niet kan. Het verplaatst ook de tellers en traces die u leest wanneer de doorvoer daalt, omdat het werk nu aan de andere kant van een grens gebeurt die u niet beheert. Beschouw dat als een debugkostenpost, niet alleen als een prestatiebeslissing.

Het creëert geen instructieondersteuning, configureert geen cipher en maakt een bestaande route niet werkend.

Virtualisatie voegt ook op deze as een vouw toe. Een gast kan een gemaskeerd CPU-model krijgen dat kenmerken verbergt die de host heeft, en een geneste gast kan nog minder zien. Lees de mogelijkhedenweergave van binnenuit de omgeving waar de VPN echt draait, niet vanaf de hypervisor-console.

Wat elke keuze koopt, en wat ze niet kan

De praktische vraag is waar de tijd naartoe gaat. Als één drukke thread, herhaalde bufferkopieën of een systeemaanroep per pakket de doorvoer beperken, kan het verplaatsen van de transformatie naar een pad dat die kosten wegneemt helpen, mits de kernel de transformatie implementeert die u nodig hebt.

Als de grens een overbelaste uplink, een pad met verlies, een lange round-trip, een verzadigde bestemmingsdienst of één thread vastgezet op één core is, verandert plaatsing niets belangrijks. Hetzelfde geldt voor de instructiekeuze: AES op toegewijde hardware kan een ontbrekende route niet repareren en helpt niet als de tunnel stil ligt omdat naamresolutie faalt.

Waar beide gelden, versterken ze elkaar. Een kernelpad kan dezelfde verdeling op instructieniveau gebruiken binnen de crypto-API van de kernel, en een pad in de gebruikersruimte met een goed gekozen bibliotheek gebruikt die al. De beslissing is niet welke in het abstracte sneller is; ze is voor welke kosten u bewijs hebt.

Noteer de vier feiten voordat u iets verandert

Noteer het service-binary en de cryptobibliotheek waaraan het is gelinkt, want die bepalen as één. Noteer daarna de onderhandelde gegevensbescherming, want een cipher zonder toegewijd instructiepad gedraagt zich anders dan een met, en de suite wordt door beide partijen gekozen.

Daarna de mogelijkhedenweergave van binnenuit de draaiende omgeving, en ten slotte het actieve pakketpad met bewijs dat de modus die u denkt dat aan staat, dat echt is. Een geladen module is geen bewijs dat een profiel hem gebruikt, en een configuratieregel is geen bewijs dat de kernel hem heeft geaccepteerd.

Verander één ding en vergelijk dan met een gelijkmatige werklast met dezelfde eindpunten en dezelfde overdrachtsrichting. Een snelheidsclaim die u niet hebt gemeten is minder waard dan een notitie dat de backend nooit ter discussie stond.