[tor-bugs] #10599 [Tor bundles/installation]: Investigate building TBB with SoftBound or AddressSanitizer

[Tor Bug Tracker & Wiki]

#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 mikeperry):

 Replying to [comment:22 gk]:
 > Replying to [comment:21 mikeperry]:
 > > gk - I have three thoughts about getting this out the door quicker in
 the best shape possible:
 > >
 > > 1. Screw lucid. Let's only support x64 and Precise+ with these builds.
 Build 4.9.0 and the ASAN+Ubsan+VTV firefox in Precise, and don't worry
 about that 4.9.0 compile error. (Though I guess this means we can't use
 the gitian-utils descriptors as-is to build this compiler with the rest of
 the tools..).
 >
 > We are not only throwing lucid but debian stable and presumably other
 distros as well out of the boat. So I'd rather avoid that at the moment if
 possible. Re: re-using descriptors: I wouldn't worry about that much
 currently as we need a separate hardening-branch anyway (e.g. we don't
 build 32bit bundles as this breaks etc.).

 Ubuntu 12.04 was released before debian/stable, so that should be OK. We'd
 only be dropping debian/oldstable, 10.04 LTS, and Centos 5 users, most
 likely. But if we can find a way to make it work on Lucid, sure.

 > > 2. Don't strip it, so stacktraces like the cyperpunks one in
 comment:16 make sense immediately without the need to make a second set of
 detached debug symbols for this build. This way we don't hit #12103
 either, and hopefully all of the other hardening options will remain in-
 tact too.
 > >
 > > 3. Install all Firefox langpack locales in one build. This way we
 don't have to ship 12 versions of this huge build. We can provide
 instructions for users on how to switch their language for now, and
 perhaps later add a Tor Launcher or other UI option to select locale for
 these builds.
 >
 > Hrm... I am not a fan of this idea for a couple of reasons:
 > 0) We need to fix #12103 anyway for non-hardened builds.

 Hrmm. Assuming it's as easy as using a newer binutils..

 > 1) Users have to download a huge build (e.g. the debug symbols file
 alone is twice as big with ASan) which might deter from testing/using it.

 Can we easily convert the stacktrace from
 http://paste.debian.net/hidden/b7b2f353/ using detached symbols? Can you
 post your symbols for that bug so I can take a look to see if it is
 possible?

 > 2) We need to provide additional instructions and/or a Tor Launcher
 patch that both need to be maintained.

 For the locale thing, I don't think this is too much of a problem compared
 to the cost to us otherwise. The alternative is an additional 15 40M files
 for each locale. It gets even more unweildy if we decide to do ASAN builds
 for all other platforms, as our dist size would then be around 4GB. I
 think we definitely want to avoid shipping two sets of bundles for all
 platforms for all locales. The only way this would be feasible is if we
 decided to only provide ASAN builds.

 In my experience, if the langpakcs are installed, all you have to do is
 switch the general.useragent.locale pref.

 > 3) (and this one is the most important to me) There might be cases where
 a stacktrace alone is not helpful for debugging, i.e. cases where we want
 things --enable-debug and --disable-optimize (and maybe others) give us.

 I suspect that symbols will be enough, here. Memory issues become much
 easier to diagnose when you catch them at the first point of illegal
 access (which is what ASAN gives us).

 > > Thoughts? I suppose an alternate way to achieve #1 might be to build a
 4.8 gcc in lucid and then use that gcc to build 4.9. Not sure which would
 mean more build time/hassle on average.
 >
 > I slightly prefer that approach to #1 if we don't find a better
 solution. It needs *once* more build time as we save the built utils (but
 this build time overhead can be quite a lot as we need to compile both
 gccs with -j1 due to autotools not liking libfaketime). Anyway, I've filed
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61314 and maybe the gcc folks
 are coming up with an easy fix/workaround for us.

 Ok.

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