pfSense: AES-NI Hardware Crypto Acceleration in KVM

Achtung! Dieser Artikel ist älter als ein Jahr. Der Inhalt ist möglicherweise nicht mehr aktuell!

Wie schon des öfteren erwähnt nutze ich in meinem Heimnetzwerk eine pfSense Firewall in einer KVM Maschine. Ich möchte mein Netzwerk in Regensburg mit dem bei meinen Großeltern zusammenschalten via einem Site-To-Site OpenVPN Konstrukt. Dazu habe ich mir die PcEngines APU.1D4 gekauft. Ein Test im lokalem Gigabit Netzwerk war aber wenig erfreulich. Die Geschwindigkeit reichte gerade so für einen HD Stream aus.

Ich hatte zuerst die vergleichsweise schwache CPU in der APU.1D4 in Verdacht, der die „moderne“ Crypto zu schaffen machen. Es stellte sich aber schnell heraus, dass diese sich nahezu langweilt und fast keine CPU Zeit verbraucht wird.

Kein durchreichen von Hardwarefeatures

Der Flaschenhals war tatsächlich auf meinem Hostsystem zu finden: Es war die CPU Einstellung des KVM Hypervisors auf meinem Hostsystem.

Damit möglichst wenig Overhead für das Vortäuschen von Hardware verwendet wird nutze ich Standard Komponenten wie die VirtIO Treiber oder die QEMU CPU. Diese unterstützt aber nicht das Durchreichen von Hardwarefeatures wie AES-NI, obwohl der Intel Core i5-4440 meines Hostsystems AES-NI hat.

Als einzige Ausnahme verwende ich als CPU für meine Firewall den Typ „Sandy Bridge“, was letzendlich einen Intel Xeon E3 Prozessor emuliert.

Nach einem Reboot spuckte dmesg folgendes aus:

Durch den emulierten Xeon Prozessor sind so gut wie alle Hardwarefeatures nun angeblich in dem FreeBSD System verfügbar, darunter auch das gewünschte Feature AES-NI.

Mit Hilfe von OpenSSL kann man prüfen, ob das Feature richtig erkannt und tatsächlich verwendbar:

Das Kernelmodul cryptodev (Ich glaube zumindest, dass es auf FreeBSD ebenfalls ein Kernelmodul ist) kann von OpenSSL verwendet werden. Vor dem Speedtest muss pfSense über die Verfügbarkeit informiert werden.

pfSense Einstellungen

Eventuell pfSense durch die „falsche“ CPU bei der Installation keine Hardwareunterstützung und hat deshalb alle Einstellungen deaktiviert. In der Weboberfläche musste ich deshalb via System -> Advanced -> Miscellaneous in der Kategorie „Cryptographic Hardware Acceleration“ die Option „AES-NI CPU-based Acceleration (aesni)“ auswählen und speichern.

Nach dem Reboot sollten nun alle Services mit Crypto vieles direkt in Hardware ausführen/berechnen lassen.

Speedtest

Nach dem Reboot habe ich mit OpenSSL einen Speedtest von AES-128-CBC durchgeführt, da diese beim Site-To-Site VPN zum Einsatz kommen soll. Die Ergebnisse lassen sich sehen:

Ohne EVP API:

Mit EVP API:

Die Ergebnisse sprechen für sich. Die EVP API erkennt die Hardware Unterstützung und nutzt diese wirklich. Filesharing via VPN macht nun auch deutlich mehr Spaß.

Further Reading:

 

Update 09.05.2016

In der Web GUI auf dem Dashboard sieht man nun die verfügbaren Hardware Cryptop Features:


Du hast einen Kommentar, einen Wunsch oder eine Verbesserung? Schreib mir doch eine E-Mail! Die Infos dazu stehen hier.

🖇️ = Link zu anderer Webseite
🔐 = Webseite nutzt HTTPS (verschlüsselter Transportweg)
Zurück