Hello,
Today I found that it is possible to force OpenSSL enable the use of CPU AES
acceleration even if it doesn't detect the "aes" CPU flag.
Many VPS hosts configure their hypervisors in a way that does not have the
flag passed through into VPSes, even though all their host nodes surely have
CPUs with support for AES-NI. In my experience hosts have not been forthcoming
in reconfiguring their systems to include that flag passthrough.
But it turns out we can force OpenSSL to believe AES is supported, even
if the CPU does not report it. This can be done with the "OPENSSL_ia32cap"
environment variable. Searching around, all I found was scenarios to use it for
disabling AES-NI (for testing), e.g.:
https://mjanja.ch/2013/11/disabling-aes-ni-on-linux-openssl/
I believe the syntax used there applies "xor" over the real flag values, e.g.
OPENSSL_ia32cap="~0x202" to disable AES. But what if you need to
force-enable it. Turns out the syntax working for that is simply:
OPENSSL_ia32cap="+0x202"
Let's take one VPS box with the aforementioned problem.
# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : QEMU Virtual CPU version 1.5.3
stepping: 3
microcode : 0x1
cpu MHz : 1695.729
cache size : 4096 KB
physical id : 0
siblings: 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 4
wp : yes
flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl eagerfpu pni cx16
hypervisor lahf_lm
bugs:
bogomips: 3391.45
clflush size: 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
As you can see "aes" is not present.
Testing OpenSSL speed in the default configuration.
# openssl speed -elapsed -evp aes-128-gcm
...
type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes
16384 bytes
aes-128-gcm 32332.17k40365.80k42265.77k42376.19k 43196.42k
43401.22k
And now we force AES hardware acceleration usage:
# OPENSSL_ia32cap="+0x202" openssl speed -elapsed -evp aes-128-gcm
...
type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes
16384 bytes
aes-128-gcm 59047.07k 104467.39k 141712.21k 151093.93k 158321.32k
156827.65k
Almost 4 times faster! For Tor this leads to higher bandwidth utilization and
lower CPU usage
(which will actually make your VPS host happier :)
But how to apply that to Tor? Well, for some initial testing I just chose to
add the following
line to /etc/init.d/tor (not using systemd here), right after "#! /bin/bash":
export OPENSSL_ia32cap="+0x202"
(but this will get overwritten and removed by the next Tor version upgrade).
Seems to work just fine, my CPU usage is half of what it was before, at similar
bandwidth levels.
So now it has headroom to ramp up further.
A word of caution, firstly always test as shown above to verify that it works.
I believe if the underlying CPU actually doesn't support AES, all programs
trying to use it,
including "openssl speed", will crash outright, with an incorrect instruction
error, or somesuch.
So there is no risk to jeopardize encryption strength or security of Tor.
Also even if it works now, it may stop working down the line if the host
migrates your VPS to
a node with older CPU, one which doesn't support AES. But migrations of
customers between do not
happen very often, and in fact all CPUs used today in a hosting environment
should support
AES, as that's been implemented in server (and even desktop) CPUs a very very
long time ago.
--
With respect,
Roman
--
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
