[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #21648 [Core Tor/Tor]: prop140: Caches generate diffs as appropriate
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs