Hello,
i wanted to share the experience in running a Tor Relay (no-exit) on a small embedded computer costing 7eur/month at oneprovider with unlimited 1Gbps bandwidth (at least they say that):
VIA Nano processor U2250 (1.6GHz Capable) 2GB Ram
I had to install to get the hw acceleration library: Tor version 0.2.8.1-alpha (git-9093e3769746742f).
In /etc/tor/torrc: HardwareAccel 1 AccelName padlock
I see with iptraf 60.000kbit/s peak with 30% uses of main CPU.
I'm wondering if that small boxes are hitting a limit of the hardware acceleration or limit of the provider or Tor network itself.
There's a way to measure the uses of the hw acceleration given by the Via Padlock, if it's at 10% of it's capacity or 100% ?
On Sun, 5 Jun 2016 13:28:04 +0200 "Fabio Pietrosanti (naif) - lists" lists@infosecurity.ch wrote:
I had to install to get the hw acceleration library: Tor version 0.2.8.1-alpha (git-9093e3769746742f).
Which OS do you use?
In my experience I had to recompile OpenSSL with the Padlock patch: https://romanrm.net/openssl-padlock And then Tor would simply crash if such patched OpenSSL is installed and HardwareAccel is enabled in torrc. However I did not try the 0.2.8.1-alpha.
In /etc/tor/torrc: HardwareAccel 1 AccelName padlock
Do you get messages about successfully using 'padlock' in /var/log/tor/log?
I see with iptraf 60.000kbit/s peak with 30% uses of main CPU.
Do you mean 60 Mbit? If so, then that's a very good result for only 30% CPU.
I'm wondering if that small boxes are hitting a limit of the hardware acceleration or limit of the provider or Tor network itself.
Remember the Tor network won't instantly use 100% of your CPU or bandwidth capabilities, it will take time to ramp up to speed: https://blog.torproject.org/blog/lifecycle-of-a-new-relay
There's a way to measure the uses of the hw acceleration given by the Via Padlock, if it's at 10% of it's capacity or 100% ?
There is no way, the only hint you have is the general CPU load.
On 6/5/16 2:17 PM, Roman Mamedov wrote:
On Sun, 5 Jun 2016 13:28:04 +0200 "Fabio Pietrosanti (naif) - lists" lists@infosecurity.ch wrote:
I had to install to get the hw acceleration library: Tor version 0.2.8.1-alpha (git-9093e3769746742f).
Which OS do you use?
In my experience I had to recompile OpenSSL with the Padlock patch: https://romanrm.net/openssl-padlock And then Tor would simply crash if such patched OpenSSL is installed and HardwareAccel is enabled in torrc. However I did not try the 0.2.8.1-alpha.
Yes, that's the way i've done the setup Tor+OpenSSL:
cd sudo DEBIAN_FRONTEND=noninteractive apt-get update sudo DEBIAN_FRONTEND=noninteractive apt-get --yes --force-yes install checkinstall build-essential sudo DEBIAN_FRONTEND=noninteractive apt-get --yes --force-yes build-dep openssl sudo rm -rf ~/openssl git clone https://github.com/openssl/openssl.git cd openssl sudo ./config sudo make sudo make test sudo checkinstall sudo rm -rf ~/openssl sudo mv /usr/bin/c_rehash /usr/bin/c_rehashBACKUP sudo mv /usr/bin/openssl /usr/bin/opensslBACKUP sudo ln -s /usr/local/ssl/bin/c_rehash /usr/bin/c_rehash sudo ln -s /usr/local/ssl/bin/openssl /usr/bin/openssl openssl version apt-cache show openssl root@dedi-fr-23644:~#
root@dedi-fr-23644:~# openssl version OpenSSL 1.1.0-pre3-dev xx XXX xxxx root@dedi-fr-23644:~# openssl engine padlock (padlock) VIA PadLock (no-RNG, ACE)
# Tor apt-get install libevent-dev wget https://www.torproject.org/dist/tor-0.2.8.1-alpha.tar.gz
cd tor-0.2.8.1-alpha
apt-get install zlib1g zlib1g-dev ./configure --with-openssl-dir=/usr/local/openssl --enable-static-openssl make make install
mv /usr/bin/tor /usr/bin/tor.orig ln -s /etc/tor/torrc /usr/local/etc/tor/torrc
# Edit /etc/tor/torrc and add HardwareAccel 1 AccelName padlock
/usr/local/bin/tor -f /etc/tor/torrc &
In /etc/tor/torrc: HardwareAccel 1 AccelName padlock
Do you get messages about successfully using 'padlock' in /var/log/tor/log?
Yes root@dedi-fr-23644:~# zgrep -i padlock /var/log/tor/log* /var/log/tor/log:Jun 05 16:58:27.000 [notice] Default OpenSSL engine for AES-128-ECB is VIA PadLock (no-RNG, ACE) [padlock]
I see with iptraf 60.000kbit/s peak with 30% uses of main CPU.
Do you mean 60 Mbit? If so, then that's a very good result for only 30% CPU.
It means that the padlock is doing it's job in making crypto acceleration.
I'm wondering if that small boxes are hitting a limit of the hardware acceleration or limit of the provider or Tor network itself.
Remember the Tor network won't instantly use 100% of your CPU or bandwidth capabilities, it will take time to ramp up to speed: https://blog.torproject.org/blog/lifecycle-of-a-new-relay
There's a way to measure the uses of the hw acceleration given by the Via Padlock, if it's at 10% of it's capacity or 100% ?
There is no way, the only hint you have is the general CPU load.
That's the point, i want to measure how the padlock hw accel is performing, to understand if it does hit it's limits or not.
I think that we need to find a way
On 6/5/16 5:01 PM, Fabio Pietrosanti (naif) - lists wrote:
Do you get messages about successfully using 'padlock' in /var/log/tor/log?
Yes root@dedi-fr-23644:~# zgrep -i padlock /var/log/tor/log* /var/log/tor/log:Jun 05 16:58:27.000 [notice] Default OpenSSL engine for AES-128-ECB is VIA PadLock (no-RNG, ACE) [padlock]
I noticed just now that we could *also* enable the hw RNG of the Padlock, to further offload the Via Nano main CPU processing:
http://www.logix.cz/michal/devel/padlock/index.xp?show_selected=1&msgid=...
Curious to see if that small server server could hit 100Mbit/s sustained traffic barrier!
Fabio
Hi,
(Batching a bunch of replies together.)
For some historical context:
* https://trac.torproject.org/projects/tor/ticket/15503
* https://trac.torproject.org/projects/tor/ticket/15918 (Still a low priority, padlock's hash accel isn't exposed in any way from OpenSSL at all.)
On Sun, 5 Jun 2016 17:11:19 +0200 "Fabio Pietrosanti (naif) - lists" lists@infosecurity.ch wrote:
On 6/5/16 5:01 PM, Fabio Pietrosanti (naif) - lists wrote:
Do you get messages about successfully using 'padlock' in /var/log/tor/log?
Yes root@dedi-fr-23644:~# zgrep -i padlock /var/log/tor/log* /var/log/tor/log:Jun 05 16:58:27.000 [notice] Default OpenSSL engine for AES-128-ECB is VIA PadLock (no-RNG, ACE) [padlock]
The important one is AES-128-CTR. Since you're using OpenSSL master, it should be accelerated. Versions prior to the 1.1 series do not.
Quickly skimming engines/e_padlock.c, it appears that GCM accel isn't supported, but I don't feel like looking at if that means "just a slow GHASH" or "slow everything".
I noticed just now that we could *also* enable the hw RNG of the Padlock, to further offload the Via Nano main CPU processing:
The tor process tries really hard to intentionally and explicitly disable support for hardware RNGs, for "we don't trust it" reasons. Eventually this code will change to force the use of a RNG that is shipped with tor.
See: src/common/crypto.c:crypto_force_rand_ssleay()
The best way to use it would be to ensure that your kernel uses entropy from it as part of the system entropy pool.
On Sun, 5 Jun 2016 18:53:50 +0200 Toralf Förster toralf.foerster@gmx.de wrote:
On 06/05/2016 01:28 PM, Fabio Pietrosanti (naif) - lists wrote:
In /etc/tor/torrc: HardwareAccel 1
Reading https://lists.torproject.org/pipermail/tor-relays/2012-March/001260.html I do wonder if setting that option is helpful ?
Padlock support, unlike AES-NI is provided as an engine, so afaik it still matters.
On Sun, 5 Jun 2016 18:20:56 +0200 fatal fatal@mailbox.org wrote:
Hello,
openssl with enabled padlock and tor stable crashes on my via nano servers running linux and freebsd.
How's it crashing, what are the versions of the relevant components? My gut feeling would be an OpenSSL bug of some sort, but please file a ticket on trac.
NB: I don't have anything with Padlock support.
On 6/5/16 9:40 PM, Yawning Angel wrote:
The important one is AES-128-CTR. Since you're using OpenSSL master, it should be accelerated. Versions prior to the 1.1 series do not.
Quickly skimming engines/e_padlock.c, it appears that GCM accel isn't supported, but I don't feel like looking at if that means "just a slow GHASH" or "slow everything".
I see that on GnuTLS they are optimizing GCM using the ECB part of Padlock: https://github.com/GostCrypt/GnuTLS/blob/master/lib/accelerated/x86/aes-gcm-...
Wondering if that can't be a choice also for OpenSSL/Tor to offload crypto a bit more?
Fabio
On Sun, 5 Jun 2016 17:01:29 +0200 "Fabio Pietrosanti (naif) - lists" lists@infosecurity.ch wrote:
Do you mean 60 Mbit? If so, then that's a very good result for only 30% CPU.
It means that the padlock is doing it's job in making crypto acceleration.
Without padlock I am seeing about 50% CPU use with 25 Mbit in + 25 Mbit out.
There's a way to measure the uses of the hw acceleration given by the Via Padlock, if it's at 10% of it's capacity or 100% ?
There is no way, the only hint you have is the general CPU load.
That's the point, i want to measure how the padlock hw accel is performing, to understand if it does hit it's limits or not.
I think that we need to find a way
It is not a separate accelerator device with its own throughput limits, it's just a set of additional instructions in the CPU. Hence as long as you see CPU load less than 100%, then no "limit" has been hit. Or if you see 100% CPU use, then there's your answer, even with the padlock support it is now saturated.
Hello,
openssl with enabled padlock and tor stable crashes on my via nano servers running linux and freebsd.
without padlock max is ~81 Mbit with linux and ~76 with freebsd (100% load, measured in the last week).
On 05.06.2016 17:22, Roman Mamedov wrote:
On Sun, 5 Jun 2016 17:01:29 +0200 "Fabio Pietrosanti (naif) - lists" lists@infosecurity.ch wrote:
Do you mean 60 Mbit? If so, then that's a very good result for only 30% CPU.
It means that the padlock is doing it's job in making crypto acceleration.
Without padlock I am seeing about 50% CPU use with 25 Mbit in + 25 Mbit out.
There's a way to measure the uses of the hw acceleration given by the Via Padlock, if it's at 10% of it's capacity or 100% ?
There is no way, the only hint you have is the general CPU load.
That's the point, i want to measure how the padlock hw accel is performing, to understand if it does hit it's limits or not.
I think that we need to find a way
It is not a separate accelerator device with its own throughput limits, it's just a set of additional instructions in the CPU. Hence as long as you see CPU load less than 100%, then no "limit" has been hit. Or if you see 100% CPU use, then there's your answer, even with the padlock support it is now saturated.
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 06/05/2016 01:28 PM, Fabio Pietrosanti (naif) - lists wrote:
In /etc/tor/torrc: HardwareAccel 1
Reading https://lists.torproject.org/pipermail/tor-relays/2012-March/001260.html I do wonder if setting that option is helpful ?
- -- Toralf PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7
tor-relays@lists.torproject.org
-
Fabio Pietrosanti (naif) - lists -
fatal -
Roman Mamedov -
Toralf Förster -
Yawning Angel