VPC routers do AES in software: the template blacklists aesni_intel and vpcrouter.sh never loads it

Ouverte
  • Quelque chose ne va pas ?
#14,429 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
45/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
java, linux
Domaine
infrastructure, networking

Piste de recherche

Start with systemvm/debian/etc/modprobe.d/aesni_intel.conf and compare the AES-NI setup in router.sh with vpcrouter.sh, which the issue says does not load the module. Check how the system VM starts services and how the CPU AES flag can be detected. Reproduce on a VPC router with AES-NI available and verify the module loads and IPsec uses AES-NI; assess the separate strongSwan replay-window suggestion and its packet loss effects.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

bug
problem

The system VM image has /etc/modprobe.d/aesni_intel.conf with "blacklist aesni_intel" (systemvm/debian/etc/modprobe.d/aesni_intel.conf, commit f498ca6 from 2012, "blacklist aesni_intel module to avoid crash"). router.sh loads the module by name (setup_aesni), but vpcrouter.sh does not. VPC routers therefore use cbc(aes-generic) for IPsec, even when the guest CPU has the aes flag.

Measured on CloudStack 4.23.0.0, guest CPU AMD EPYC-Rome, router with 4 vCPUs, iperf3 across a site-to-site tunnel:

  • stock template, ESP aes256-sha256: 0.61 to 0.82 Gbit/s, with one router vCPU at 100% softirq;
  • with aesni_intel loaded, ESP aes256-sha256: 1.05 to 1.25 Gbit/s;
  • with aesni_intel loaded, IKE and ESP AES-GCM: 1.40 to 1.55 Gbit/s.

Related: with AES-NI, GCM encryption runs on several vCPUs and reorders ESP packets. strongSwan's default charon.replay_window of 32 then drops packets as replays (XfrmInStateSeqError reached 126,700 in one test), and multi-stream throughput fell to about 1.0 Gbit/s. "charon { replay_window = 1024 }" in /etc/strongswan.d/ fixed it (0 drops).

versions

System VM template 4.22.0 and earlier. CloudStack 4.23.0.0. KVM with a guest CPU model that exposes aes (host-model).

The steps to reproduce the bug
  1. Create a VPC on KVM with a host CPU that has AES-NI and a guest CPU model that exposes it.
  2. On the VPC router, read /proc/cpuinfo (the aes flag is there), /proc/modules (no aesni_intel) and /proc/crypto (cbc(aes) uses aes-generic).
  3. Create a site-to-site VPN and run iperf3 across it. One router vCPU sits at 100% softirq.
What to do about it?

Load aesni_intel on VPC routers too, when the CPU has the aes flag. We use a systemd unit with ConditionCPUFeature=aes that runs "modprobe aesni_intel" at boot. The 2012 crash may not apply to current kernels; we saw no kernel error in our tests. Also consider a larger charon.replay_window, for example 1024.

Langage dominant
Java
Étoiles
3.1k
Forks
1.4k
Merge moyen
7 j 16 h
PR mergées (30 j)
15

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de apache/cloudstack

Toutes les issues de apache/cloudstack

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.