OpenSSL 1.0.1 and AES-NI



  • There are already a couple of posts about openssl with aes-ni on this forum. As they don't show me a clear picture, I just tested myself the openssl performance with the current LiveCD pfSense 2.1-BETA1-amd64-20130407-0250 being installed as KVM VM (plain, without any virtio or further configurations). The host has a Intel Core i7-3770 3.4GHz CPU with the 'aes'/AES-NI feature always enabled for all VMs.

    Result: openssl 1.0.1e has the aes-ni performance only if the crypto hw setting is set to none and the aesni.ko module is not loaded (scenario 2). Is this a bug or expected behavior?

    Scenario 1: pfSense with module, but no performance
    dmesg:      aesni0 <aes-cbc,aes-xts> on motherboard
    kldstat:    aesni.ko loaded
    Crypto HW:  AES-NI CPU-based Acceleration 
    –----------------------------------------------------
    /usr/bin/openssl speed -evp aes-128-cbc -elapsed
    OpenSSL 0.9.8y 5 Feb 2013
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
    aes-128-cbc      15112.61k    56426.88k   174954.66k   372524.95k   236635.04k
    
    /usr/local/bin/openssl speed -evp aes-128-cbc -elapsed
    OpenSSL 1.0.1e 11 Feb 2013
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
    aes-128-cbc      15003.38k    56277.06k   174802.81k   371585.72k   229122.01k</aes-cbc,aes-xts>
    
    Scenario 2: pfSense without module, but with same performance as the host
    dmesg:      aesni0 <aes-cbc,aes-xts> on motherboard
    kldstat:    no aesni.ko
    Crypto HW:  None
    –----------------------------------------------------
    /usr/bin/openssl speed -evp aes-128-cbc -elapsed
    OpenSSL 0.9.8y 5 Feb 2013
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
    aes-128-cbc     164469.41k   182946.87k   191618.21k   196323.05k   197930.83k  
    
    /usr/local/bin/openssl speed -evp aes-128-cbc -elapsed
    OpenSSL 1.0.1e 11 Feb 2013
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
    aes-128-cbc     615347.13k   655957.97k   667286.62k   668656.00k   670887.10k   <===</aes-cbc,aes-xts>
    
    Scenario 3: host itself or other Linux VMs and openssl 1.0.1x
    –----------------------------------------------------
    openssl speed -evp aes-128-cbc -elapsed
    OpenSSL 1.0.1c 10 May 2012
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
    aes-128-cbc     616457.53k   657153.13k   667808.43k   670501.55k   671312.55k
    


  • As a followup, I quickly tested the speed of openvpn (ip fastforwarding enabled):
    knoppix VM –(openVPN)--> pfsense VM ---> Internet ---> download mirror

    without openvpn: 45MB/s
    with openvpn, without aesni.ko: 4-6MB/s, 30-40% CPU
    with openvpn, with aesni.ko: 4-6MB/s, 30-40% CPU

    Is the openvpn of pfSense using the aes-ni at all?


  • Rebel Alliance Developer Netgate

    I split this off into its own topic since it is more of an AES-NI question than directly related to that other thread.

    We have observed some similar issues (see the other threads about AES-NI, especially http://forum.pfsense.org/index.php/topic,54008.0.html ) but we don't have any AES-NI capable hardware in our lab yet to tinker with.

    Having the AES-NI module loaded hooks into the crypto system of FreeBSD so that IPsec can take advantage of it, and OpenVPN will latch on as well.

    OpenSSL 1.0.1e does have its own AES-NI code, but the way it selects its engine is based on which ciphers have registered engines. If there is an engine that offers to support AES, it will be used over OpenSSL's internal code. That explains why it is slower with AES-NI loaded no matter what you select in the OpenVPN engine list.

    In this case it would appear that OpenSSL's internal code handles AES-NI better than FreeBSD's crypto engine hooking into AES-NI but why that is the case exactly, I'm not sure. There may be some other bit for FreeBSD's AES-NI code that we're missing or that needs setup/optimized in some way.


Log in to reply