Tor Browser for ARM architecture

[mttp]

The Tor Project should provide a Tor Browser compatible with the ARMv7 processor. This would provide a safe way of using Tor for users of the Samsung ARM Chromebook, the Samsung Chromebook 2, the Raspberry Pi, the Novena Open Laptop, and probably other platforms too.

[mirimir]

I've built Firefox in Tor Browser 4.5a4 on a Raspberry Pi 2, running Raspbian wheezy on a 32GB class 10 microSDHC card. It took 6-7 hours at 100% CPU, and I had to cool the Pi 2 with a small fan to prevent overheating. I followed the instructions in <https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking> at "Building Just Firefox" exactly, except that I commented out "ac_add_options --enable-tor-browser-update" in "~/tor-browser/.mozconfig" after configuring.

As instructed, I overwrote the Firefox folder in tor-browser_en-US (from tor-browser-linux32-4.5a4_en-US.tar.xz) with the Firefox folder from the build. Had I been using just the one Pi, that would have been sufficient. However, given that I'm using this workspace Pi with a Tor gateway Pi, a little tweaking was required.

To avoid the possibility of Tor over Tor, I deleted the Tor folder in Tor Browser. In order to have Tor Browser run without a local tor process, I added two lines to "prefs.js" in the profiles:

| user_pref("extensions.torlauncher.prompt_at_startup", false);
| user_pref("extensions.torlauncher.start_tor", false);

Once Tor Browser would run, I changed SocksPort to "192.168.2.1:9150", and disabled the TorLauncher extension. All of the expected extensions are present. On the gateway Pi, I used this "/etc/tor/torrc":

| SocksPort 127.0.0.1:9050
| SocksPort 192.168.2.1:9050
| SocksPort 192.168.2.1:9100
| SocksPort 192.168.2.1:9150
|
| SocksPolicy accept 127.0.0.1
| SocksPolicy accept 192.168.2.0/16
| SocksPolicy reject *
|
| DnsPort 127.0.0.1:53 IsolateDestPort
| DnsPort 192.168.2.1:53 IsolateDestPort
|
| VirtualAddrNetwork 10.192.0.0/10
| AutomapHostsOnResolve 1
|
| ControlPort 9151
| CookieAuthentication 1
|
| Log notice file /var/log/tor/notices.log
| RunAsDaemon 1
| DataDirectory /var/lib/tor

I don't believe that the iptables rules on the gateway Pi are relevant here, but I'll be happy to add them if desired. I installed torsocks and rinetd on the workspace Pi, and used this "/etc/rinetd.conf":

| bindaddress bindport connectaddress connectport
| 127.0.0.1 9050 192.168.2.1 9050
| 127.0.0.1 9151 192.168.2.1 9151

Browsing <​https://check.torproject.org>, I get that that the browser is using Tor, and there's no warning that it's not Tor Browser. After hitting "New Tor Circuit for this Site" in Torbutton, the page reloads with a new IP address. However, Torbutton still complains that Tor isn't running, and I don't know how to fix that.

I also plan to test a deterministic build from <​https://git.torproject.org/builders/tor-browser-bundle.git>. But I presume that would depend on having some version of Ubuntu with Gitian running on Raspberry Pi. I know of two possibilities so far: Ubuntu 14.04 LTS <​https://wiki.ubuntu.com/ARM/RaspberryPi> and Ubuntu 14.10 / Linaro 15.01 <​http://www.raspberrypi.org/forums/viewtopic.php?f=56&t=98997>. I gather that they differ in how they're compiled for ARMv7 and ARMHF.

[dawuud]

I built Tor Browser in arch linux running on a Raspberry Pi 2.
I followed this procedure:
https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking#BuildingJustFirefox

I'd like to make many further refinements to my archlinux build procedure for TBB such as using distcc with cross compiling slaves etc.

Here's a brief explanation of how to build tor-browser in arm arch linux:

First, I git cloned ​https://git.torproject.org/tor-browser.git
and I checked out the "tor-browser-31.5.3esr-4.5-1-build1" branch.

Then I followed the instructions and performed prerequisite changes as described here:
​https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Linux_Prerequisites

1. install prerequisite arch packages:

pacman -Syu --needed base-devel zip unzip freetype2 fontconfig pkg-config \

gtk2 dbus-glib iw libidl2 python2 mercurial alsa-lib curl libnotify libxt \
mesa autoconf2.13 yasm wireless_tools gstreamer0.10 \
gstreamer0.10-base-plugins libpulse

2. edit .mozconfig

here's the things i changed:

[human@builder tor-browser]$ git diff .mozconfig
diff --git a/.mozconfig b/.mozconfig
index f2874e8..73fd025 100755
--- a/.mozconfig
+++ b/.mozconfig
@@ -2,14 +2,22 @@

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-@CONFIG_GUESS@
mk_add_options MOZ_APP_DISPLAYNAME="Tor Browser"

-mk_add_options MOZ_MAKE_FLAGS="-j4"
+mk_add_options MOZ_MAKE_FLAGS="-j2"

mk_add_options MOZILLA_OFFICIAL=1
mk_add_options BUILD_OFFICIAL=1

+
+mk_add_options PYTHON=/usr/bin/python2
+mk_add_options AUTOCONF=autoconf-2.13
+
+ac_add_options --with-ccache=/usr/bin/ccache
+ac_add_options --with-arm-kuser
+ac_add_options --with-arch=armv7-a
+

ac_add_options --enable-optimize
#ac_add_options --disable-optimize
ac_add_options --enable-official-branding

-ac_add_options --enable-tor-browser-update
+#ac_add_options --enable-tor-browser-update

ac_add_options --enable-update-packaging
ac_add_options --enable-signmar
ac_add_options --enable-verify-mar

@@ -21,3 +29,4 @@ ac_add_options --disable-maintenance-service

ac_add_options --disable-crashreporter
ac_add_options --disable-webrtc
#ac_add_options --disable-ctypes

+
[human@builder tor-browser]$

remarks about this .mozconfig:

• I am using ccache... So don't set that ccache option unless you are also going to use ccache.

• I use MOZ_MAKE_FLAGS="-j2" because the Raspberry Pi 2 only has 1G of ram.

Additionally I enabled 1G of swap on this build system so that it wouldn't crash with out-of-memory failures.

3. building archlinux Tor Browser Bundle

I followed the procedure documented here:
https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking#BuildingJustFirefox

I used the most recent amd64 build of TBB for the skeleton... and replaced it's browser with the new as mentioned in the link.

[cypherpunks]

While building tor-browser 5.5-1 on a debian jessie arm system (qemu, vexpress-a9), e.g.:

QEMU_AUDIO_DRV=none qemu-system-arm -m 1024M -sd jessie_armhf.img -M vexpress-a9 -cpu cortex-a9 -kernel jessie_armhf_vmlinuz_extracted -initrd jessie_armhf_initrd_extracted -append "root=/dev/mmcblk0p2 console=ttyAMA0"  -no-reboot -net nic -net user -dtb vexpress-v2p-ca9.dtb  -nographic -redir tcp:5555::22

I followed the build instructions from https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking, with no further modifications to build options.

e.g.

make $CONFIGURE_ARGS -f client.mk configure CONFIGURE_ARGS="--with-tor-browser-version=5.5-1"
make $MAKEOPTS -f client.mk build

The build options for media/libvpx specify -mfloat-abi=softfp, which breaks the arm-linux-gnueabihf toolchain as it is missing gnu/stubs-soft.h.

​https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795331

Applying the author's suggested fix:

diff --git a/media/libvpx/moz.build b/media/libvpx/moz.build
index a1138f4..999ca94 100644
--- a/media/libvpx/moz.build
+++ b/media/libvpx/moz.build
@@ -65,7 +65,8 @@ if CONFIG['VPX_ARM_ASM']:

     for f in SOURCES:
         if f.endswith('.c') and 'neon' in f:
-            SOURCES[f].flags += ['-march=armv7-a', '-mthumb', '-mfloat-abi=softfp', '-mfpu=neon']
+            SOURCES[f].flags += ['-mfpu=neon']
+    #        SOURCES[f].flags += ['-march=armv7-a', '-mthumb', '-mfloat-abi=softfp', '-mfpu=neon']

and the build proceeds. I'm not sure if this fix would break platforms (e.g. Rpi 1)

[cypherpunks]

Reporting from a Novena here. I built Tor Browser from source and set preferences to use the system Tor as shown in the start_tor_browser script. I'm running it through Xpra due to unstable drivers, so I don't have graphical acceleration. It took maybe 11 hours to compile. So it's quite slow, but not unusable I don't think. The main lag seems to be in downloading pages.

The main problems I see is that from my initial glance I didn't see Gitian working on ARM. If it requires virtualization, that's out of the question given most ARM boards don't support those hardware extensions. There may have to be containers used for reproducible builds if they aren't already.

[teor]

Replying to cypherpunks:

The main problems I see is that from my initial glance I didn't see Gitian working on ARM. If it requires virtualization, that's out of the question given most ARM boards don't support those hardware extensions. There may have to be containers used for reproducible builds if they aren't already.

You could use a cross-compiler that runs on x86_64 but targets ARM.

It's what we do for our Windows and OS X builds.

[cypherpunks]

Ubuntu-vm-builder (python-vm-builder), used by gitian, already supports multiple architectures, but lacks the release information for releases of ubuntu or debian for any cpu architectures other than i686 and x86_64.

gitian also supports using LXC, via libvirt, instead of Qemu-KVM. This is used by default when the gitian environment is already virtualized. libvirt also supports using a qemu backend, for example, qemu-system-arm.

Debian is also supported as a target by gitian, and debian supports a wider variety of architectures than ubuntu. A patch for python-vm-builder that includes all flavors of debian releases would be a step towards getting gitian to support other target architectures.

[c6h12o6]

Successful compilation of Tor Browser on ASUS C201 running libreboot[1] and Debian Stretch with mainline kernel[2] following https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking#BuildingJustFirefox (and adding "ac_add_options --disable-gstreamer" to tor-browser/.mozconfig as Stretch doesn't ship gstreamer0.10) took estimated 2h.

Please reconsider officially supporting this architecture, we'd really appreciate being able to use Tails[3] on such a fast and affordable device we can trust that much.

[1] ​https://libreboot.org/docs/hcl/c201.html
[2] linux-image-armmp-lpae, cf. ​https://wiki.debian.org/InstallingDebianOn/Asus/C201#Mainline_Linux_Kernel
[3] cf. ​https://labs.riseup.net/code/issues/10972

[arma]

This weekend I ran into a person who was trying to hack his Firefox on arm (raspberry pi) to do the things Tor Browser does. It sure would be better if we had even unofficial builds, and even if it's only whichever arm arch is easier (maybe that's armv8?).

Is the issue that we don't have the build farm infrastructure? Or does it not build? Or does it build, but not reproducibly?

[gk]

Replying to arma:

Is the issue that we don't have the build farm infrastructure? Or does it not build? Or does it build, but not reproducibly?

Definitely the first. But we need to write Gitian descriptors for building for ARM first and I suspect there are a bunch of our myriad of components that are trickier to cross-compile than others. And, yes, I assume there will be reproducibility issues. In short: I guess this will be a non-trivial amount of work.

That said: I'd be happy if a cypherpunk would show up trying to do this and would help them getting this done.

[gk]

Moving over to rbm