Re: [tor-bugs] #24116 [Core Tor/Torsocks]: Torsocks deadlocks every Rust program

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs