Opened 11 years ago

Last modified 7 years ago

#907 closed defect (Fixed)

HardwareAccel isn't used

Reported by: udo Owned by:
Priority: Low Milestone:
Component: Core Tor/Tor Version: 0.2.0.32
Severity: Keywords:
Cc: udo, arma, nickm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Log shows me:

[info] crypto_global_init(): Initializing OpenSSL via tor_tls_init().

but crypto.c says:

if (useAccel < 0) {

log_info(LD_CRYPTO, "Initializing OpenSSL via tor_tls_init().");

}
if (useAccel > 0) {

log_info(LD_CRYPTO, "Initializing OpenSSL engine support.");
ENGINE_load_builtin_engines();
if (!ENGINE_register_all_complete())

return -1;

So no HardwareAccel even though torrc says:

HardwareAccel 1

This is Fedora 10 on VIA EK8000. Tor 0.2.0.32, built with source and spec from tor.eff site.

[Automatically added by flyspray2trac: Operating System: Fedora Core Linux]

Child Tickets

Change History (17)

comment:1 Changed 11 years ago by udo

# openssl engine
(padlock) VIA PadLock (no-RNG, ACE)
(dynamic) Dynamic engine loading support

Patched openssl, of course.

comment:2 Changed 11 years ago by nickm

I can't for the life of me figure out what is calling tor_tls_init before crypto_global_init() gets called. I've
tried to reproduce this on 0.2.0.32-dev, 0.2.0.32, and trunk, and had no luck. crypto_global_init() was called from
tor_init each time.

Can you use gdb to set a breakpoint inside crypto_global_init(), run Tor, and check the stack trace to see the first
place where crypto_global_init() is called for you?

Posting your torrc might be useful too.

comment:3 Changed 11 years ago by udo

torrc:

SocksPort 9050 # what port to open for local application connections
SocksListenAddress 127.0.0.1 # accept connections only from localhost
DataDirectory /var/lib/tor
ControlPort 9051
HashedControlPassword blabla
Nickname blabla
Address blabla
ContactInfo Random Person blabla
ORPort 9001
ExitPolicy reject *:* # middleman only -- no exits allowed
BandwidthRate 20 KB
BandwidthBurst 21000
HardwareAccel 1
AccountingStart day 12:21
AccountingMax 2 GB
User _tor

Is there a quick gdb howto for the asked breakpoint test or is it very easy to figure out?

comment:4 Changed 11 years ago by nickm

Start gdb with "gdb path/to/tor"

Then say "break crypto.c:180", where instead of 180, you say the line where you want to put a breakpoint.

Then say "run". If you start Tor with command-line arguments, give them after this "run".

GDB will stop when it hits the breakpoint. When this happens, say "bt" to get a stack trace.

comment:5 Changed 11 years ago by udo

(gdb) run -f /etc/tor/torrc --pidfile /var/run/tor/tor.pid
Starting program: /usr/bin/tor -f /etc/tor/torrc --pidfile /var/run/tor/tor.pid
[Thread debugging using libthread_db enabled]
Jan 21 16:10:07.640 [notice] Tor v0.2.0.32 (r17346). This is experimental software. Do not rely on it for strong anonymity. (Running on Linux i686)
Jan 21 16:10:07.648 [notice] Initialized libevent version 1.4.5-stable using method epoll. Good.
Jan 21 16:10:07.652 [notice] Opening OR listener on 0.0.0.0:9001
Jan 21 16:10:07.656 [notice] Opening Socks listener on 127.0.0.1:9050
Jan 21 16:10:07.659 [notice] Opening Control listener on 127.0.0.1:9051
[New Thread 0xb7ff1a40 (LWP 585)]

Breakpoint 1, crypto_global_init (useAccel=-1) at crypto.c:180
180 _crypto_global_initialized = 1;
(gdb) bt
#0 crypto_global_init (useAccel=-1) at crypto.c:180
#1 0x080d95bc in tor_tls_init () at tortls.c:304
#2 0x080d9972 in tor_tls_context_new (identity=0x811e618, key_lifetime=7200) at tortls.c:530
#3 0x080b104f in init_keys () at router.c:515
#4 0x08094f6b in accounting_set_wakeup_time () at hibernate.c:462
#5 configure_accounting (now=1232550607) at hibernate.c:361
#6 0x080641ea in options_act () at config.c:1227
#7 set_options (new_val=0x8115530, msg=0xbffff6a4) at config.c:753
#8 0x08064e10 in options_init_from_torrc (argc=5, argv=0xbffff8d4) at config.c:3704
#9 0x0809632d in tor_init (argc=5, argv=0xbffff8d4) at main.c:1802
#10 0x080994e7 in tor_main (argc=5, argv=0xbffff8d4) at main.c:1985
#11 0x080c6fe7 in main (argc=1, argv=0x8000) at tor_main.c:29

comment:6 Changed 11 years ago by nickm

Thanks! This should be fixed in r18210.

comment:7 Changed 11 years ago by udo

Where can I see that patch/diff so I can test the change?

Thanks in advance for the info.

(full tree of 2.0.32 with patch is also OK)

comment:8 Changed 11 years ago by nickm

You could check out the latest revision from subversion:

http://www.torproject.org/documentation#Developers

This patch hasn't been backported to the stable branch yet, since we're trying to do a stable release today, and this
needs more testing.

comment:10 Changed 11 years ago by udo

Thanks!
Unfortunately the patch doesn't work right away; after some fiddling I run into issues with crypto_seed_rng that was changed after 2.0.32 was released (I guess).
I think I'll have to wait for tor 2.0.33. (with hopefully this fix)

comment:11 Changed 11 years ago by nickm

No, the fix for this one will have to go into 0.2.0.34; 0.2.0.33 is coming out today, and there isn't time to test
this fix enough.

comment:12 Changed 11 years ago by udo

0.2.0.34 does not mention bug 907?

comment:13 Changed 11 years ago by arma

Correct. I don't think we're going to backport it to 0.2.0 after all, since
we're trying to reduce the number of changes we make to the 'stable' release.

0.2.1.12-alpha has your fix though.

comment:14 Changed 11 years ago by udo

How stable is 0.2.1.12 if that isn't a stable release?
In other words, with respect for the decision, what will I get?

comment:15 Changed 11 years ago by nickm

Alpha releases come with all the guarantees that the stable series does, which is to say: "no guarantees at all". ;) We
try hard to make sure they all work, but the fact that alphas often have new features or complex fixes (like this one)
means that they are likelier to have new bugs than releases in the stable series.

That said, I run the alphas, and they works for me, usually. If they don't work for you, it should be easy to move
back to 0.2.0.x until the next version of 0.2.1.x comes out.

comment:16 Changed 11 years ago by nickm

flyspray2trac: bug closed.

comment:17 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.