Skip to content

GitLab

Last edited by intrigeri
Page history

ARM_platforms

This is about tails#10972.

Related pages

Pros & cons

Pros

  • It is likely that cheap laptops are going to be more and more often based on ARM. So, supporting ARM would have several advantages:

    • People who can't afford a more expensive computer might more easily afford a ARM-based one ⇒ supporting Tails on ARM would make it more accessible economically speaking.
    • It could allow more people to dedicate a machine to Tails, which can have a number of advantages, such as: one can choose a machine that they can carry with them all the time (⇒ physical security of the hardware); one avoids the risk of their (adversary -owned) non-Tails operating system corrupting the firmware in a way that can in turn compromise Tails.

  • Most mobile touch devices, e.g. tablets, are based on ARM these days (tails#6064 (closed)).

  • Some concerns about (Intel) x86 technologies, like the Intel ME, might be less of a problem for the time being on ARM. This is no magic wand, though: as Joanna Rutkowska writes in her State considered harmful paper, "there is nothing special in ARM-based architecture that could prevent a vendor from introducing backdoors into the SoCs they produce".

Cons

  • A huge amount of work is needed to make this happen, since it impacts basically all kinds of teams and skills: user support, release process and workload, infrastructure, quality assurance, Installation Assistant + DAVE, etc.

  • This has the potential to spread our energy a bit too thinly, e.g. in terms of maintenance workload, or in terms of acquiring maintaining and knowledge and skills.

  • There are lots of unknowns: boot loaders, drivers and hardware support. It's an entirely new world for most of us ⇒ in the current state of things, it is hard to estimate the resources we would need to make it happen.

  • Tor Browser is not supported on ARM yet.

Other remarks

  • It might be a good thing, for the Tails project, to have a big thing to do together, that at least one people from each team would need to be somewhat involved in.

  • The Tor project may be interested in supporting ARM platforms better (e.g. for Tor Browser). This could be a good opportunity to (learn how to) work together more tightly, be it on the technical or fundraising / paperwork side.

Hardware

Lists of devices

Useful, up-to-date lists of devices can be found there:

CPU architecture

Current (mid-2014 to early 2016) ARM Chromebooks have one of:

For Jessie, https://www.debian.org/releases/stable/armhf/ch02s01.html.en reads:

  • Debian/armhf works only on newer 32-bit ARM processors which implement at least the ARMv7 architecture with version 3 of the ARM vector floating point specification (VFPv3). It makes use of the extended features and performance enhancements available on these models.

  • Debian/arm64 works on 64-bit ARM processors which implement at least the ARMv8 architecture.

⇒ armhf should support all current ARM Chromebooks.

Also, 64-bit ARM CPUs can apparently run code that was compiled for armhf.

⇒ armhf should support all ARM Chromebooks for the foreseeable future.

Update one year later — April 2017, some ARMv8 (64-bit) ones have appeared:

On the 32-bit front, a few RK3288-based tablets and media boxes keep appearing, but the latest 32-bit ARM Chromebook was released in 2015-11.

Drivers

Debian

Let's see how current (early 2016) Debian supports ARM Chromebooks.

XXX: update this section with newer information, e.g. after we've managed to boot a Debian kernel on an Acer Chromebook R 13.

How others handle it

Kali provides one image per supported system (list of images, documentation). Their build scripts display lots of machine-specific variations, e.g. kernel version, additional drivers and firmware, X.Org and ALSA configuration.

Arch Linux provides one image per supported board, and indeed their installation instructions point to a different rootfs tarball, each with a different kernel, e.g. the peach (ChromeOS 3.8 armv7h kernel), veyron (ChromeOS 3.14 armv7h kernel), oak (ChromeOS 3.18 aarch64 kernel) ones. But they also have more generic images, e.g. ARMv7 Multi-platform, ARMv7 Chromebook, and ARMv8 AArch64 Multi-platform ones, that ship with the mainline kernel and a bunch of dtb files. It's not clear how doable it would be to create an image that works well on devices that have different boards: including all the needed dtb files seems easy, but is there a single (e.g. ChromeOS) kernel version that has all the needed drivers and firmware?

The Arch Linux ARM PKGBUILDs repository have all their ARM-specific changes. In particular:

Bootloader

Chromebooks

On Chromebooks, one can "flash" a custom bootloader in the place where the kernel would usually be found by the embedded bootloader. This allows booting an OS in a more "traditional" way than what the included bootloader requires, and brings a number of advantages, such as: ability to edit the kernel command line, booting from external storage without pressing CTRL+U (if that bootloader is installed on the internal storage), bootloader menu (think "Troubleshooting Mode").

More information:

Coreboot

Sadly, the "legacy boot" mode that makes it "easy" to boot another OS than ChromeOS, thanks to the SeaBIOS payload of coreboot, is not available on ARM.

XXX: is Coreboot or U-Boot installed on ARM Chromebooks? https://www.coreboot.org/Chromebooks lists only X86 devices.