[tor-bugs] #21648 [Core Tor/Tor]: prop140: Caches generate diffs as appropriate

[Tor Bug Tracker & Wiki]

#21648: prop140: Caches generate diffs as appropriate
---------------------------------------+-----------------------------------
 Reporter:  nickm                      |          Owner:  nickm
     Type:  defect                     |         Status:  merge_ready
 Priority:  Medium                     |      Milestone:  Tor:
                                       |  0.3.1.x-final
Component:  Core Tor/Tor               |        Version:
 Severity:  Normal                     |     Resolution:
 Keywords:  prop140 TorCoreTeam201704  |  Actual Points:  5
Parent ID:  #13339                     |         Points:  2
 Reviewer:                             |        Sponsor:  Sponsor4
---------------------------------------+-----------------------------------

Comment (by nickm):

 I think I figured it out.

 This happens when we go to allocate something fairly big in a worker
 thread, ''AND'' the linux seccomp2 sandbox is turned on, ''AND'' we're
 using the standard glibc allocator and not some other thing that took over
 for the glibc allocator.  We never ran into this before, since the current
 workers don't allocate much.

 Right now we have a 1-MB limit on how much RAM we allow the seccomp2
 sandbox to mprotect(PROT_READ|PRO_WRITE) at once.  I guess that that's not
 good enough for the threads, and it's trying to mprotect() more.

 To confirm, I'll dump the syscall arguments for the above backtrace:

 {{{
 Thread 2 "tor" received signal SIGSYS, Bad system call.
 [Switching to Thread 0x7ffff447c700 (LWP 2851)]
 0x00007ffff5fdee97 in mprotect () from /lib64/libc.so.6
 Missing separate debuginfos, use: dnf debuginfo-install keyutils-
 libs-1.5.9-8.fc24.x86_64 krb5-libs-1.14.4-7.fc25.x86_64
 libcom_err-1.43.3-1.fc25.x86_64 libevent-2.0.22-1.fc25.x86_64
 libgcc-6.3.1-1.fc25.x86_64 libscrypt-1.21-2.fc24.x86_64
 libseccomp-2.3.2-1.fc25.x86_64 libselinux-2.5-13.fc25.x86_64
 libzstd-1.1.3-1.fc25.x86_64 openssl-libs-1.0.2k-1.fc25.x86_64
 pcre-8.40-7.fc25.x86_64 xz-libs-5.2.2-2.fc24.x86_64
 zlib-1.2.8-10.fc24.x86_64
 (gdb) print $rdi
 $1 = 140737155325952
 (gdb) print $rsi
 $2 = 8880128
 (gdb) print $rdx
 $3 = 3
 }}}


 That's `mprotect(0x7fffec266000, 880128, PROT_READ|PROT_WRITE`.

 Short-term solution -- raise MALLOC_MP_LIM.

 Longer-term solution -- make the seccomp2 sandbox wiser about interned
 strings.  We'll want to do that anyway here.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21648#comment:15>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online