AES-NI dans OpenSSL ou déport vers le noyau : laquelle vous faut-il ?

Deux étiquettes sont employées comme si elles désignaient la même chose : accéléré par le matériel et déporté dans le noyau. L’une décrit quelles instructions exécute la routine AES d’une bibliothèque, l’autre décrit où le traitement des paquets a lieu. Un VPN peut avoir la première sans la seconde, la seconde sans la première, ou les deux à la fois. Toute décision sur les performances doit commencer par nommer laquelle des deux vous modifiez réellement.

Deux axes, pas une note

Le premier axe est l’implémentation : le code qui fait de l’AES-256-GCM est-il dirigé vers une version qui utilise les instructions dédiées du processeur, ou vers une routine portable qui les exécute comme de l’arithmétique ordinaire. Ce choix vit à l’intérieur de la bibliothèque cryptographique et se fait à son initialisation.

Le second axe est le placement : le paquet traverse-t-il le chemin de transformation du noyau, ou un démon en espace utilisateur lit-il depuis un périphérique tunnel, chiffre-t-il et réécrit-il.

Aucun axe ne contraint l’autre. Un VPN en espace utilisateur sur un processeur doté des instructions AES peut les utiliser tout le temps, et un chemin noyau sur un processeur qui en est dépourvu retombe sur une implémentation logicielle. Les étiquettes des documents fournisseurs font rarement cette distinction, et c’est pourquoi les conseils de réglage copiés d’une situation à l’autre ne font si souvent rien.

Axe un : quel code effectue le chiffrement

OpenSSL détecte les caractéristiques du processeur lors de l’initialisation et se sert du résultat pour choisir des chemins de code optimisés, comme le décrit la documentation des capacités x86. AES-NI est l’une des capacités documentées derrière cette répartition. Rien de tout cela n’exige que la bibliothèque devienne un composant du noyau.

Confirmez que la caractéristique est visible pour le processus avant de supposer que le chemin rapide est emprunté. Sous Linux, la source est le champ flags de /proc/cpuinfo, et dans un invité il reflète ce qu’expose l’hyperviseur et non le nom de modèle de l’hôte physique.

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

La seconde commande nomme les fournisseurs chargés dans cette compilation. Elle ne vous dit pas quelle bibliothèque le service VPN a liée, et un hôte peut porter deux installations d’OpenSSL tandis que le processus en cours n’en utilise qu’une.

Axe deux : où s’exécute le chemin des paquets

Placer dans le noyau signifie que la transformation a lieu dans la machinerie IPsec du noyau lui-même ou dans un pilote de tunnel au sein du noyau, de sorte que les paquets n’ont pas besoin d’un aller-retour par un processus en espace utilisateur pour chaque lot. Cela peut réduire les copies et les changements de contexte, et répartir le travail sur les cœurs comme ne peut le faire un démon mono-thread. Cela déplace aussi les compteurs et les traces que vous lirez quand le débit chute, car le travail se fait désormais de l’autre côté d’une frontière que vous ne contrôlez pas. Considérez cela comme un coût de débogage, pas seulement comme une décision de performance.

Cela ne crée pas de support d’instructions, ne configure pas de chiffrement et ne fait pas fonctionner une route existante.

La virtualisation ajoute un pli sur cet axe aussi. Un invité peut recevoir un modèle de processeur masqué qui cache des caractéristiques que l’hôte possède, et un invité imbriqué peut en voir encore moins. Lisez la vue des capacités depuis l’intérieur de l’environnement où le VPN tourne réellement, pas depuis la console de l’hyperviseur.

Ce que chaque choix achète, et ce qu’il ne peut pas

La question pratique est où passe le temps. Si un seul thread occupé, des copies de tampon répétées ou un appel système par paquet limitent le débit, déplacer la transformation vers un chemin qui supprime ces coûts peut aider, à condition que le noyau implémente la transformation dont vous avez besoin.

Si la limite est une liaison montante saturée, un chemin avec pertes, un temps d’aller-retour long, un service de destination saturé ou un thread épinglé à un cœur, le placement ne change rien d’important. Il en va de même pour le choix des instructions : l’AES sur matériel dédié ne répare pas une route manquante et n’aidera pas si le tunnel est inactif parce que la résolution de noms échoue.

Là où les deux s’appliquent, ils se composent. Un chemin noyau peut utiliser la même répartition au niveau des instructions dans l’API cryptographique du noyau, et un chemin en espace utilisateur avec une bibliothèque bien choisie l’utilise déjà. La décision n’est pas laquelle est la plus rapide dans l’abstrait ; c’est pour quel coût vous avez des preuves.

Notez les quatre faits avant de changer quoi que ce soit

Notez le binaire du service et la bibliothèque cryptographique à laquelle il est lié, car ce sont eux qui décident de l’axe un. Puis consignez la protection des données négociée, car un chiffrement sans chemin d’instructions dédié se comporte différemment d’un chiffrement qui en a un, et la suite est choisie par les deux pairs.

Ensuite, la vue des capacités depuis l’intérieur de l’environnement en cours d’exécution, et enfin le chemin de paquets actif avec la preuve que le mode que vous croyez activé l’est vraiment. Un module chargé n’est pas la preuve qu’un profil l’utilise, et une ligne de configuration n’est pas la preuve que le noyau l’a acceptée.

Changez une chose, puis comparez avec une charge de travail constante, mêmes extrémités et même sens de transfert. Une affirmation de vitesse que vous n’avez pas mesurée vaut moins qu’une note disant que le backend n’a jamais été mis en doute.