[tor-bugs] #21010 [Applications/Tor Browser Sandbox]: Disable RDTSC/RDTSCP to limit side-channel attacks

Tor Bug Tracker & Wiki blackhole at torproject.org
Sun Dec 18 02:41:18 UTC 2016


#21010: Disable RDTSC/RDTSCP to limit side-channel attacks
----------------------------------------------+-------------------------
 Reporter:  cypherpunks                       |          Owner:  yawning
     Type:  enhancement                       |         Status:  new
 Priority:  High                              |      Milestone:
Component:  Applications/Tor Browser Sandbox  |        Version:
 Severity:  Normal                            |     Resolution:
 Keywords:                                    |  Actual Points:
Parent ID:                                    |         Points:
 Reviewer:                                    |        Sponsor:
----------------------------------------------+-------------------------

Comment (by cypherpunks):

 Replying to [comment:5 yawning]:
 > I'm somewhat worried that RDTSC use ends up depending on distribution,
 and what the user is doing.  Maybe I'm being overly paranoid here...
 Using instructions like that require explicit `asm()` directives, so
 things like specific toolchain configuration won't matter. Unless the code
 explicitly opts-in to using it, it won't be used, and unless a
 distribution uses it in a library linked in by Firefox, it won't be used.
 As far as I know, there are no system libraries which have configuration
 flags to enable using TSC instructions, since it's detected based on the
 host target instead. So something like glibc will always pull in a pthread
 implementation that uses `RDTSC` on architectures which support it (i.e.
 all x86_64 processors), on all distributions. Likewise with
 `__libc_fork()` (which becomes the `__fork` symbol). This is because
 `sysdeps/x86_64/hp-timing.h` defines `HP_TIMING_AVAIL` to be 1 by default,
 with a comment saying that they always assume the timestamp register is
 present. So on all x86_64 Linux systems, regardless of distribution, the
 behavior will be the same.

 We could check the recursive library dependencies in a few major
 distributions and disassemble them and check for instances of `RDTSC` as I
 did on my own system (Gentoo, and a rather stripped down one with fewer
 libraries than something bloated like Ubuntu or Mint). If there are no
 more relevant uses of TSC instructions in linked in libraries, then
 there's no realistic reason Firefox would end up running into it. It's not
 like it uses self-modifying or misaligned code to trick disassemblers. If
 there ever is an obscure distro which happens to configure a library in
 such a way that it pulls in a new library as a dependency, and the new
 library uses a TSC instruction illegally, it should be trivial to work
 around.

 Quite a few libraries are used by Firefox and its dependencies, yet I
 found only three problematic uses of `RDTSC`, all in the most obvious
 library: libc. Given that, it seems pretty unlikely that other distros
 that pull in an extra library or two because of a special configuration
 are going to end up causing segfaults.

 Of all these libraries, only one was obviously problematic (libc), and one
 was potentially problematic (libxul):

 {{{
 $ cd /usr/local/lib64/tor-browser
 $ lddtree -l firefox *.so | sort -u | wc -l
 92
 }}}

 I think it is paranoid to worry that it will end up depending on
 distribution, given how it's a ubiquitous architectural thing. I'm
 confident that we won't be chasing endless distro-specific bugs.

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


More information about the tor-bugs mailing list