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

Offen
  • Stimmt etwas nicht?
#14,429 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
45/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
java, linux
Bereich
infrastructure, networking

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Java
Sterne
3.1k
Forks
1.4k
Ø Merge
7 T. 16 Std.
Gemergte PRs (30 T.)
15

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus apache/cloudstack

Alle Issues in apache/cloudstack

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.