AES-NI in OpenSSL o offload nel kernel: quale serve davvero?

Due etichette vengono usate come se fossero la stessa cosa: accelerato via hardware e spostato nel kernel. Una descrive quali istruzioni esegue la routine AES di una libreria, l’altra descrive dove avviene l’elaborazione dei pacchetti. Una VPN può avere la prima senza la seconda, la seconda senza la prima o entrambe insieme. Qualsiasi decisione sulle prestazioni deve iniziare nominando quale delle due state davvero cambiando.

Due assi, non un punteggio

Il primo asse è l’implementazione: il codice che esegue AES-256-GCM viene indirizzato a una versione che usa le istruzioni dedicate del processore o a una routine portabile che le esegue come aritmetica ordinaria. Questa scelta vive dentro la libreria crittografica e viene fatta alla sua inizializzazione.

Il secondo asse è la collocazione: il pacchetto attraversa il percorso di trasformazione del kernel o un demone nello spazio utente legge da un dispositivo tunnel, cifra e riscrive.

Nessun asse vincola l’altro. Una VPN nello spazio utente su una CPU con istruzioni AES può usarle per tutto il tempo, e un percorso nel kernel su una CPU che ne è priva ricade su un’implementazione software. Le etichette nei materiali dei fornitori raramente fanno questa distinzione, ed è per questo che i consigli di regolazione copiati tra le due situazioni così spesso non fanno nulla.

Asse uno: quale codice esegue la cifratura

OpenSSL rileva le caratteristiche del processore durante l’inizializzazione e usa il risultato per scegliere percorsi di codice ottimizzati, come descrive la documentazione sulle capacità x86. AES-NI è una delle capacità documentate dietro questo smistamento. Nulla di ciò richiede che la libreria diventi un componente del kernel.

Verifica che la caratteristica sia visibile al processo prima di dare per scontato che si usi il percorso rapido. Su Linux la fonte è il campo flags di /proc/cpuinfo, e dentro un ospite riflette ciò che espone l’hypervisor e non il nome del modello dell’host fisico.

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

Il secondo comando nomina i provider caricati in quella build. Non dice quale libreria abbia collegato il servizio VPN, e un host può portare due installazioni di OpenSSL mentre il processo in esecuzione ne usa solo una.

Asse due: dove gira il percorso dei pacchetti

La collocazione nel kernel significa che la trasformazione avviene nella macchina IPsec del kernel stesso o dentro un driver tunnel nel kernel, così i pacchetti non hanno bisogno di un andata e ritorno attraverso un processo nello spazio utente per ogni lotto. Questo può ridurre copie e cambi di contesto e distribuire il lavoro tra i core come un demone a thread singolo non può. Sposta anche i contatori e le tracce che leggerai quando il throughput cala, perché il lavoro ora avviene dall’altra parte di un confine che non controlli. Consideralo un costo di debug, non solo una decisione sulle prestazioni.

Non crea supporto per le istruzioni, non configura una cifratura e non fa funzionare un percorso esistente.

La virtualizzazione aggiunge una piega anche su questo asse. A un ospite può essere dato un modello di CPU mascherato che nasconde caratteristiche che l’host possiede, e un ospite annidato può vederne ancora meno. Leggi la vista delle capacità dall’interno dell’ambiente in cui la VPN gira davvero, non dalla console dell’hypervisor.

Cosa compra ogni scelta, e cosa non può

La domanda pratica è dove va il tempo. Se un solo thread occupato, copie ripetute del buffer o una chiamata di sistema per pacchetto limitano il throughput, spostare la trasformazione su un percorso che elimina quei costi può aiutare, purché il kernel implementi la trasformazione che ti serve.

Se il limite è un uplink congestionato, un percorso con perdite, un tempo di andata e ritorno lungo, un servizio di destinazione saturo o un thread fissato a un core, la collocazione non cambia nulla di importante. Vale lo stesso per la scelta delle istruzioni: AES su hardware dedicato non ripara un percorso mancante e non aiuterà se il tunnel è inattivo perché la risoluzione dei nomi fallisce.

Dove valgono entrambe, si compongono. Un percorso nel kernel può usare lo stesso smistamento a livello di istruzioni dentro l’API crittografica del kernel, e un percorso nello spazio utente con una libreria ben scelta lo usa già. La decisione non è quale sia più veloce in astratto; è per quale costo hai prove.

Annota i quattro fatti prima di cambiare qualcosa

Annota il binario del servizio e la libreria crittografica a cui è collegato, perché sono questi a decidere l’asse uno. Poi registra la protezione dei dati negoziata, perché una cifratura senza percorso di istruzioni dedicato si comporta diversamente da una che lo ha, e la suite è scelta da entrambe le parti.

Poi la vista delle capacità dall’interno dell’ambiente in esecuzione e infine il percorso dei pacchetti attivo con la prova che la modalità che credi abilitata lo sia davvero. Un modulo caricato non è prova che un profilo lo usi, e una riga di configurazione non è prova che il kernel l’abbia accettata.

Cambia una cosa, poi confronta con un carico di lavoro costante con gli stessi estremi e la stessa direzione di trasferimento. Un’affermazione di velocità che non hai misurato vale meno di una nota che dica che il backend non è mai stato in dubbio.