[tor-relays] Force OpenSSL AES-NI usage on a VPS without the AES CPU flag passthrough

[teor]

> On 22 Aug 2017, at 16:22, Roman Mamedov <rm at romanrm.net> wrote:
> 
> 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.

This would be a great addition to tor/doc/TUNING.

Does someone want to summarise it and submit a patch to:
https://trac.torproject.org

(I'd open a ticket, but trac is having temporary performance issues.)

Here's the existing TUNING file:

https://gitweb.torproject.org/tor.git/tree/doc/TUNING

> 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="~0x200000200000000" to disable AES. But what if you need to
> force-enable it. Turns out the syntax working for that is simply:
> 
>  OPENSSL_ia32cap="+0x200000200000000"
> 
> 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 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
> aes-128-gcm      32332.17k    40365.80k    42265.77k    42376.19k  43196.42k    43401.22k
> 
> And now we force AES hardware acceleration usage:
> 
> # OPENSSL_ia32cap="+0x200000200000000" openssl speed -elapsed -evp aes-128-gcm
> ...
> type             16 bytes     64 bytes    256 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="+0x200000200000000"
> 
> (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.

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org
------------------------------------------------------------------------



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20170823/91c105cb/attachment.sig>