[tor-bugs] #10599 [Tor bundles/installation]: Investigate building TBB with SoftBound or AddressSanitizer
Tor Bug Tracker & Wiki
blackhole at torproject.org
Wed Jun 4 06:01:07 UTC 2014
#10599: Investigate building TBB with SoftBound or AddressSanitizer
------------------------------------------+--------------------------------
Reporter: mikeperry | Owner: erinn
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Tor bundles/installation | Version:
Resolution: | Keywords: gitian, tbb-
Actual Points: | security
Points: | Parent ID:
------------------------------------------+--------------------------------
Comment (by gk):
Here comes some material reflecting my failures to build bundles on Lucid
with 4.9.0 so far (progress with Precise is a different comment). The
short story is: Tor Browser (and FWIW plain Firefox as well) is
segfaulting in the packaging step with something like:
{{{
Executing /home/ubuntu/build/tor-browser/obj-x86_64-unknown-linux-
gnu/dist/bin/xpcshell -g /home/ubuntu/build/tor-browser/obj-x86_64
-unknown-linux-gnu/dist/bin/ -a /home/ubuntu/build/tor-browser/obj-x86_64
-unknown-linux-gnu/dist/bin/ -f /home/ubuntu/build/tor-
browser/toolkit/mozapps/installer/precompile_cache.js -e
precompile_startupcache("resource://gre/");
ASAN:SIGSEGV
=================================================================
==22869==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000
(pc 0x000000000000 sp 0x2b0f084bf678 bp 0x2b0f084bf780 T2)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ??:0 ??
Thread T2 created by T0 here:
#0 0x2b0ec8ea572a in __interceptor_pthread_create
../../.././libsanitizer/asan/asan_interceptors.cc:183
#1 0x2b0ef7b75269 in _PR_CreateThread /home/ubuntu/build/tor-
browser/nsprpub/pr/src/pthreads/ptthread.c:444
#2 0x2b0ef7b778ae in PR_CreateThread /home/ubuntu/build/tor-
browser/nsprpub/pr/src/pthreads/ptthread.c:527
#3 0x2b0ede4a9286 in nsThread::Init() /home/ubuntu/build/tor-
browser/xpcom/threads/nsThread.cpp:332
#4 0x2b0ee5d7d57c (/home/ubuntu/build/tor-browser/obj-x86_64-unknown-
linux-gnu/dist/bin/libxul.so+0x1bdfe57c)
==22869==ABORTING
}}}
This is not an issue with our Gitian setup as it happens with plain Lucid,
too. It is neither fixed by using GCC master although this gives me a
different crash:
{{{
Executing /home/gk/asan/mozilla-esr24/obj-x86_64-unknown-linux-
gnu/dist/bin/xpcshell -g /home/gk/asan/mozilla-esr24/obj-x86_64-unknown-
linux-gnu/dist/bin/ -a /home/gk/asan/mozilla-esr24/obj-x86_64-unknown-
linux-gnu/dist/bin/ -f /home/gk/asan/mozilla-
esr24/toolkit/mozapps/installer/precompile_cache.js -e
precompile_startupcache("resource://gre/");
=================================================================
==22303==ERROR: AddressSanitizer: unknown-crash on address 0x2ad2d31bd3c0
at pc 0x2ad2d1803362 bp 0x7fff8f6149c0 sp 0x7fff8f6149b8
READ of size 16 at 0x2ad2d31bd3c0 thread T0
#0 0x2ad2d1803361 in nsIDHashKey ../../dist/include/nsHashKeys.h:375
#1 0x2ad2d1803361 in nsBaseHashtableET
../../dist/include/nsBaseHashtable.h:408
#2 0x2ad2d1803361 in nsTHashtable<nsBaseHashtableET<nsIDHashKey,
nsFactoryEntry*> >::s_InitEntry(PLDHashTable*, PLDHashEntryHdr*, void
const*) ../../dist/include/nsTHashtable.h:472
#3 0x2ad2d179ad39 in PL_DHashTableOperate /home/gk/asan/mozilla-esr24
/obj-x86_64-unknown-linux-gnu/xpcom/build/pldhash.cpp:630
#4 0x2ad2d1805d75 in nsTHashtable<nsBaseHashtableET<nsIDHashKey,
nsFactoryEntry*> >::PutEntry(nsID const&, mozilla::fallible_t const&)
../../dist/include/nsTHashtable.h:184
#5 0x2ad2d1805d75 in nsTHashtable<nsBaseHashtableET<nsIDHashKey,
nsFactoryEntry*> >::PutEntry(nsID const&)
../../dist/include/nsTHashtable.h:170
#6 0x2ad2d1805d75 in nsBaseHashtable<nsIDHashKey, nsFactoryEntry*,
nsFactoryEntry*>::Put(nsID const&, nsFactoryEntry* const&,
mozilla::fallible_t const&) ../../dist/include/nsBaseHashtable.h:147
#7 0x2ad2d1805d75 in nsBaseHashtable<nsIDHashKey, nsFactoryEntry*,
nsFactoryEntry*>::Put(nsID const&, nsFactoryEntry* const&)
../../dist/include/nsBaseHashtable.h:141
#8 0x2ad2d1806065 in
nsComponentManagerImpl::RegisterCIDEntryLocked(mozilla::Module::CIDEntry
const*, nsComponentManagerImpl::KnownModule*) /home/gk/asan/mozilla-
esr24/xpcom/components/nsComponentManager.cpp:502
#9 0x2ad2d1809d35 in
nsComponentManagerImpl::RegisterModule(mozilla::Module const*,
mozilla::FileLocation*) /home/gk/asan/mozilla-
esr24/xpcom/components/nsComponentManager.cpp:453
#10 0x2ad2d180aba2 in nsComponentManagerImpl::Init() /home/gk/asan
/mozilla-esr24/xpcom/components/nsComponentManager.cpp:389
#11 0x2ad2d17a1fb0 in NS_InitXPCOM2 /home/gk/asan/mozilla-
esr24/xpcom/build/nsXPComInit.cpp:467
#12 0x406d4b in main /home/gk/asan/mozilla-
esr24/js/xpconnect/shell/xpcshell.cpp:1566
#13 0x2ad2d59b6c8c in __libc_start_main (/lib/libc.so.6+0x1ec8c)
#14 0x407ea0 (/home/gk/asan/mozilla-esr24/obj-x86_64-unknown-linux-
gnu/dist/bin/xpcshell+0x407ea0)
0x2ad2d31bd3c0 is located 0 bytes inside of global variable
'kComponentManagerCID' from '/home/gk/asan/mozilla-
esr24/xpcom/build/nsXPComInit.cpp' (0x2ad2d31bd3c0) of size 16
SUMMARY: AddressSanitizer: unknown-crash
../../dist/include/nsHashKeys.h:375 nsIDHashKey
Shadow bytes around the buggy address:
0x055ada62fa20: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9
0x055ada62fa30: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9
0x055ada62fa40: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9
0x055ada62fa50: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9
0x055ada62fa60: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9
=>0x055ada62fa70: 00 00 f9 f9 f9 f9 f9 f9[00]00 f9 f9 f9 f9 f9 f9
0x055ada62fa80: 07 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 04 f9 f9 f9
0x055ada62fa90: f9 f9 f9 f9 00 02 f9 f9 f9 f9 f9 f9 00 00 00 00
0x055ada62faa0: 05 f9 f9 f9 f9 f9 f9 f9 06 f9 f9 f9 f9 f9 f9 f9
0x055ada62fab0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x055ada62fac0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
ASan internal: fe
==22303==ABORTING
}}}
Not sure if that is after or even before the crash described above. Issues
with the packaging step are neither happening with GCC 4.8.2 for x86-64 on
Lucid nor with GCC 4.9.0 on Precise.
Looking closer neither setting the HOST_* flags to '" "' nor using gold as
the linker is fixing the problem. Comparing the build log of a Precise and
a Lucid build does not give any clue either. After examining the code it
seemed that the last rev that is probably working for us is
482026b63e8a488d6b7f0eab53fcbfe12c3309ae (although that one is broken due
to https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=58868).
That guess turned out to be wrong actually. After some more bisecting I
found the culprit: 4fc7b5acfc1d42a0701c8fff726a3ebe7f563dd9. I've filed a
GCC bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61408) and hope that
the GCC folks can help us here one way or another. Meanwhile, I am writing
a patch that fixes this problem for us.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10599#comment:31>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list