[tor-bugs] #24116 [Core Tor/Torsocks]: Torsocks deadlocks every Rust program
Tor Bug Tracker & Wiki
blackhole at torproject.org
Thu Nov 2 14:52:57 UTC 2017
#24116: Torsocks deadlocks every Rust program
---------------------------------------------+-------------------------
Reporter: larsl | Owner: dgoulet
Type: defect | Status: new
Priority: Medium | Milestone:
Component: Core Tor/Torsocks | Version:
Severity: Major | Resolution:
Keywords: torsocks deadlock rust jemalloc | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
---------------------------------------------+-------------------------
Comment (by larsl):
I have made an attempt at fixing this in the branch rust_deadlock_fix in
https://github.com/larsluthman/torsocks.git .
It consists of two commits, the first one simply changes the static
initialiser for the mutexes torsocks uses from PTHREAD_MUTEX_INITIALIZER
to PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP where that is available, which
makes a second pthread_mutex_lock() call in the same thread return an
error instead of invoking undefined behaviour (which includes the
deadlock) and also calls abort() instead of assert() when that error
occurs, to avoid allocating memory which can cause further problems if
we're currently in the bootstrap code for a custom allocator.
On my system (Debian 9.2, i686) this makes the Rust programs that
previously deadlocked abort immediately instead. The mutex change
shouldn't have any significant effect on performance since they only get
used during initialisation.
The second one makes torsocks's syscall() wrapper less eager to call
tsocks_initialize(), so that it only gets called for syscall numbers that
explicitly need it, such as those that are redirected to other syscalls
intercepted by torsocks. For syscalls that are redirected to actual libc
functions, or that are blocked, tsocks_initialize() is not called,
particularly not for MMAP (which would cause a recursive allocation when
mmap was called by a custom allocator, since tsocks_initialize() tries to
allocate memory when calling dlopen()) or OPEN (which would cause an
allocation attempt before jemalloc was finished bootstrapping, since it
tries to open some /proc files to check system characteristics).
On my system this makes Rust programs work with torsocks again - instead
of deadlocking or aborting they simply print {{{"1509634181 WARNING
torsocks[15489]: [syscall] Unsupported syscall number 5. Denying the call
(in tsocks_syscall() at syscall.c:571)"}}} and continues.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24116#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list