Tor Browser for ARM architecture

added TorBrowserTeam201904 component::applications/tor browser gitlab-tb-tor-browser-build priority::medium severity::normal status::needs-revision tbb-rbm type::project labels

Trac:
Cc: N/A to gk

Trac:
Keywords: N/A deleted, needs-triage added

Trac:
Keywords: needs-triage deleted, tbb-gitian added
Component: Tor bundles/installation to Tor Browser

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":

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.

Trac:
Username: mirimir

Trac:
Cc: gk to gk, mcs

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

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

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.

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.

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)

Trac:
Severity: N/A to Normal
Sponsor: N/A to N/A

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.

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.

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.

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

Trac:
Username: c6h12o6
Reviewer: N/A to N/A

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?

Trac:
Cc: gk, mcs to gk, mcs, arma

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.

Moving over to rbm

Trac:
Keywords: tbb-gitian deleted, tbb-rbm added

Trac:
Cc: gk, mcs, arma to gk, mcs, arma, boklm

Trac:
Cc: gk, mcs, arma, boklm to gk, mcs, arma, boklm, intrigeri

I've been working on rbm descriptors for building for ARM target, and I successfully built Tor's Firefox fork with rbm. Caveats:

Code is very messy (e.g. commented out code everywhere), I need to clean it up a lot.
Still based on the ESR 52 version of Tor Browser; making ESR 60 work will mean figuring out how to get Rust to build (see next item).
The only rbm project I've tried to build is Firefox and its dependencies; it's unclear how much work will be involved in building the other projects (e.g. tor, the Go projects, and the Rust projects).
The workarounds for missing target libraries (i.e. using apt-get to download armhf packages and extracting them to a prefix directory) are kind of weird, maybe there's a simpler approach than what I did?
I want to generalize the cross-compiling stuff some more, so that in the future we could add aarch64, ppc64be, and ppc64le targets without code duplication. Right now the cross-compiling stuff is hardcoded for armhf, which is great for a proof-of-concept but not a good idea to consider merging.
I haven't tested build reproducibility. I don't expect any problems here, but it's too early to be confident.

All that said, if anyone would like to play with it, the source code is at https://notabug.org/JeremyRand/tor-browser-build/src/armhf (it's in the armhf branch), and some random documentation is at https://wiki.raptorcs.com/wiki/Porting/Tor_Browser . I've successfully run the resulting Firefox binary on my Asus C201 Chromebook (running Debian Stretch) and it works fine.

Replying to JeremyRand:

All that said, if anyone would like to play with it, the source code is at https://notabug.org/JeremyRand/tor-browser-build/src/armhf (it's in the armhf branch), and some random documentation is at https://wiki.raptorcs.com/wiki/Porting/Tor_Browser . I've successfully run the resulting Firefox binary on my Asus C201 Chromebook (running Debian Stretch) and it works fine.

It looks like there is still a lot left to do, but very nice work!

Tor Browser for ARM architecture

Child items 0

Activity