Tails

#1 Updated by N9iu7pk 2016-01-18 20:06:05

1.) setup the build platform

- (OK) target/test platforms are odroid, rpi 2 and beaglebone black

- (OK) build platforms are amd64

- (OK) cross compile and build arm7 packages * failed with any cross compiler < gcc 5 * success with chroot (qemu-debootstrap)

- (OK) port at least one package installable and runnable to (armhf) rpi 2
- (in Progess) build the final build machine/platform

2.) (in Progress) build all tails packages for armhf

3.) live-buider for armhf (uBoot …)

#2 Updated by N9iu7pk 2016-01-18 20:18:44

The current platform seems not to bee suitable (laptop 2 x i5 HT, 6GB RAM), takes too long to compile i.e Icedove > 1 day, overheats etc. I’m going to setup another more stable environment.

#3 Updated by Dr_Whax 2016-01-18 20:21:09

Hey, if you have any issues with the development environment, feel free to send an e-mail to the tails-dev list :)

Is there a repo where we could follow the amazing progress you’re doing on this?

#4 Updated by Kurtis 2016-01-19 00:59:40

The ASUS Chromebook C201, which is ARM based, was ported to Libreboot recently. You can find more info here: https://libreboot.org/docs/hcl/c201.html

This is the first computer that you can buy brand new, instead of second hand, that runs with Libreboot. Libreboot is a coreboot distribution (distro) with proprietary software removed, intended to be a free (libre) ‘BIOS’ replacement for your computer. Libreboot has many practical advantages over proprietary boot firmware, such as faster boot speeds and better security. You can install GNU/Linux with encrypted /boot/, verify GPG signatures on your kernel, put a kernel in the flash chip and more.

Tails already warns users that it can not protect them from Bios or firmware attacks: https://tails.boum.org/doc/about/warning/index.en.html#index3h1

"It is also impossible for Tails to protect against attacks made through the BIOS or other firmware embedded in the computer. These are not managed or provided by the operating system directly, and no operating system can protect against such attacks.

See for example, this attack on BIOS by LegbaCore."

More info on the LightEater BIOS attack can be found here:
https://www.youtube.com/watch?v=sNYsfUNegEA
http://www.wired.com/2015/03/researchers-uncover-way-hack-bios-undermine-secure-operating-systems/

Porting Tails to ARM would allow users to buy a new ASUS Chromebook C201, port it to Libreboot using the very simple instructions, and write protect the Flash Chip with a turn of a screw: https://libreboot.org/docs/hcl/c201.html#thescrew

Users could then have the ability run this machine with a free as in freedom BIOS replacement, which is write protected, and run the most secure operating system known to man, Tails, on it.

Intel chips no longer respects user’s freedom: https://libreboot.org/faq/#intel

Porting Tails to ARM is a necessity unless something changes at Intel. Currently, all post-2008 Intel chips are to be avoided by those who value their freedom.

#6 Updated by N9iu7pk 2016-01-21 22:00:15

Next step: Set up a new build / compile environment which could also hold a repro …

#7 Updated by N9iu7pk 2016-01-21 22:01:52

—
Best Regards!
n9iu7pk

PGP pool.sks-keyservers.net 0x14F81DBA
5BF7 D75D 9DB7 AF12 496D F89B AC1B 9765 14F8 1DBA

redmine@labs.riseup.net:
> Is there a repo where we could follow the amazing progress you’re doing on this?
Currently not. I’m still working on the first complete build of all
packages and I’m getting more and more in trouble with my hardware (i5
dual core 6GB RAM) - it is running around the clock … I’m looking for
a VM running in a regional hackerspace - which could also be a repro.
And YES, I’ll write to tails-dev …

#8 Updated by N9iu7pk 2016-01-31 11:37:29

New public key:

PGP ID 0x4D12FFCB
Fingerprint 7426 4598 B5AD 4D12 1699 C710 D602 E331 4D12 FFCB

#12 Updated by intrigeri 2016-02-10 17:11:53

I don’t understand: why are you rebuilding all packages, instead of just the Tails -specific ones (that are not in Debian)?

Do we have Tor Browser for arm?

#13 Updated by Anonymous 2016-02-11 00:26:29

intrigeri wrote:
> Do we have Tor Browser for arm?

Kind of, you’ll just have to build it yourself, see https://trac.torproject.org/projects/tor/ticket/12631

#14 Updated by intrigeri 2016-02-11 01:30:54

>> Do we have Tor Browser for arm?
> Kind of, you’ll just have to build it yourself, see https://trac.torproject.org/projects/tor/ticket/12631

… and without Gitian, if I got it right by merely skimming over the recent changes on that ticket.

#15 Updated by N9iu7pk 2016-02-11 07:36:21

intrigeri wrote:
> I don’t understand: why are you rebuilding all packages, instead of just the Tails -specific ones (that are not in Debian)?
I tried to build only the packages from repository http://deb.tails.boum.org/ … that repository is requriered / requested when building a tails ISO.

With the first steps on physical armhf platforms (cortex a15) I tried to work out packages to be rebuild: I tried to run the live builder until the point where he starts to build a bootable medium/ISO - to get if possibe a full chrootable tails (based on jessie) on armhf without rebuilding anything. Failed because of any armhf packages are missed on http://deb.tails.boum.org/.

I would be very glad about any hints/help to reduce the list of packages to rebuild!

> … and without Gitian, if I got it right by merely skimming over the recent changes on that ticket.
YES!

#16 Updated by N9iu7pk 2016-02-11 07:54:17

The last weeks I worked on the build environment:

- tried armhf cortex a9 and a15 images running with qemu-system-arm (with 4GB RAM and 4 cores) similar to whats done in https://trac.torproject.org/projects/tor/ticket/12631: Anyhow, too slow to compile or test anything. On the same hardware running a virtual armhf machine a chroot enviroment compiles much much more faster than any pysical armhf hardware or an armhf virtual machine. And for tests - physical hardware (phi 2 or odroid) is much much more faster than a virtual armhf machine on a 4 x i7 ht …
- still got no local “home” for my virtual build machine to publish the work. But still not finished the search … also got a plan b and plan c … needs still some time.

#17 Updated by intrigeri 2016-02-11 10:43:06

> I would be very glad about any hints/help to reduce the list of packages to rebuild!

Replied on tails-dev@ already :)

I hadn’t noticed you had asked the question in two different places. Let’s avoid this, OK?

#22 Updated by N9iu7pk 2016-02-17 19:25:59

Current state:
==
torbrowser MISSING,
see https://trac.torproject.org/projects/tor/ticket/12631
i2p PARTIAL, same as with grub2 (tcg.c:1683: tcg fatal error)
liveusb-creator FAILED, not investigated yet
mesa SUCCESS but not tested
tails-greeter SUCCESS but not tested
tails-installer FAILED, not investigated yet
tails-iuk FAILED, not investigated yet
tails-perl5lib FAILED, not investigated yet
tails-persistence-setup FAILED, not investigated yet
torbirdy SUCCESS but not tested
vidalia SUCCESS and tested (rpi 2)
whisperback FAILED, not investigated yet
window-picker-applet FAILED, not investigated yet
grub2
-> failed, reason:

/build/qemu-1000/qemu-2.1+dfsg/tcg/tcg.c:1683: tcg fatal error

the orgigin crash message points to this code:

#ifdef CONFIG_PROFILER
s->del_op_count;
#endif

—> Multithread issue, patch
see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769983
and [2] http://patches.linaro.org/patch/32473/
—> seems that https://packages.debian.org/jessie/qemu has
not fixed this problem …

The patch described in [2] must be applied
to line 4410 (instead of 4334 as pointed in [2])
in qemu-2.1.0/linux-user/syscall.c
(the currently installed/used qemu-arm-static)

—> no further resarch, if there’s a more general fix at work
or already published
(even if

" Running multi-threaded code can easily expose some of the
fundamental breakages in QEMU’s design. It’s just not a well
supported scenario. "

it could take some time to be fixed properly …)

—> if not available applying quickfix and rebuild quemu-arm-static …
—> currently no idea if and how the build “performace” would be
affected by pinning to one single CPU …

#23 Updated by N9iu7pk 2016-02-17 19:27:05

OK … cut & past is not always the best choice … :)

#25 Updated by N9iu7pk 2016-02-17 20:27:26

Thanks to intrigeri for adding the blueprint!

> 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”

Yes I agree. But in general, I think, it is very very difficult to prove that only a particular/dedicated hardware platform is not corrupted. And there would never be general way to prove any arbritray hardware platform to be not corrupted.

But as less complex a platform is designed, as more possible could be a read-only hardware platform as Joanna proposed as stateless laptop. Usually cheap arm based platforms are built less complex, open hardware developments as odrid are more possible on less complex architectures.

#26 Updated by intrigeri 2016-02-18 16:36:00

> liveusb-creator FAILED, not investigated yet

You can skip that one, it’s been obsoleted by tails-installer. I’ve now removed it from our stable and devel APT suites where it still was (by mistake).

> window-picker-applet FAILED, not investigated yet

Same as liveusb-creator, our bad ⇒ removed.

#27 Updated by N9iu7pk 2016-02-21 19:54:54

Thanks.

Re-built qemu (qemu-system-arm … qemu-user-static …) with fix http://patches.linaro.org/patch/32473/ …

i2p does not build any more (no surprise … :( )
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (mutex.cpp:1097), pid=28943, tid=4133883904
# guarantee(no_safepoint_check || Self->is_Java_thread()) failed: invariant
-> clear what’s the issue: single core / threaded qemu-user-static schroot armhf must run jdk which requires a multithreaded environment …
-> no idea at the moment
- schroot without qemu-debootstrap?
- “native” build environment?
- looking for a better fix in qemu?
- …

grub2 builds “more”, fails later with:
/bin/cp: cannot stat ‘debian/tmp/obj/grub-rescue-pc/grub-rescue-cdrom.iso’: No such file or directory
dh_install: cp -a debian/tmp/obj/grub-rescue-pc/grub-rescue-cdrom.iso debian/grub-rescue-pc/usr/lib/grub-rescue/ returned exit code 1
debian/rules:404: recipe for target ‘override_dh_install’ failed
-> looks like an error in the make file, ‘grub-rescue-pc’ is not dedicated to be built in arm environments.

#28 Updated by Kurtis 2016-04-26 18:45:30

Anyone have any updates on this potential project?

Post-2008 Intel hardware doesn’t respect user’s freedom: https://libreboot.org/faq/#intel

You can’t have security without freedom.

Due to this, the Tails community should really consider supporting Arm.

This would allow users to run modern hardware (post-2008) with LibreBoot which would protects against this known BIOS attack: https://tails.boum.org/doc/about/warning/index.en.html#index3h1

#30 Updated by N9iu7pk 2016-04-30 04:31:24

With qemu-arm chroot environments I ended up with a qemu tcg multithread issue, I think https://www.redhat.com/archives/libvir-list/2015-May/msg00303.html will explain this in general. It is already reported (i.e. https://bugs.launchpad.net/qemu/+bug/1098729 or https://bugs.launchpad.net/qemu/+bug/668799). A quite dirty fix (single threaded pinned to a single core) failed to build i2p - cause of java needs a multithreaded environment. I pulled into deeper and found, that there is no quick/short solution in near time.

I’ve now set up a small native arm platform [raspberry pi 2 (armv7 hf) 4 cores, 1GB RAM] - runs similar performant as the qemu-arm multi core intel platform 4 cores, 8GB RAM. I set up the working storage device crypted to test/stress whether a small device may run properly with crypted storage. Runs well/performant for the moment.

So long, “binaries” of grub and i2p have been build without errors.

It’s clear - the pi is not one of the preferred platforms, due to closed hardware development. But it is small, cheap and easy to setup … more suitable platform could be the odroid (hardkernel).

#31 Updated by Dr_Whax 2016-06-04 00:16:00

Hey! Any update? Is there a git repo somewhere? I’d be happy to assist, I have a Novena board i’d like to play more with!

#32 Updated by N9iu7pk 2016-06-06 08:54:52

No news, grub2 and some others still not building, see attached status file. But I’m suffering from a lack of time to investigate.

Git repository: There is no need of a git repository … take a look at http://deb.tails.boum.org/dists/devel/main/source/Sources - these are all the packages to build for tails - except the themes (and as I guess vidalia, which will be replaced by onioncircuits).

If these packages - specially grub2 - are built to deb’s, they’ll be added to a local repository to be used by the live ISO creator in addition to debians arm.deb’s. I think, there’s no massive hacking or adopting to hardware required.

BUT - I should set up a documentation, probabely as git repository, to enable you and others to work on these topics. I’ll do this the next days.

If you have any idea, why grub2 does not want to create that iso, write please! All other packages seems to be caused by missing packages.

#34 Updated by intrigeri 2016-06-06 10:19:09

> Git repository: There is no need of a git repository

Some bits in our main Git repo are x86-specific, so sooner or later, you will definitely need to work on them, and then you’ll want a Git repo.

#35 Updated by N9iu7pk 2016-06-25 02:57:08

To document all the work I’ve done for the moment, I’ve set up a github repository: https://github.com/n9iu7pk/Tails2Arm
And yes intrigeri, I’ll need a source code git repository. But not for the moment, I’m struggling still building all not x86 specific packages. Maybe I’m faced with the first x86 specifics: grub2 fails while trying to create rescue iso’s - which is forced by an “install” build target. I still do not understand why the “install” target (which does intel specific tasks) is required to build the grub2 package.

#37 Updated by LABRADOR 2016-12-04 22:28:59

What is the current status of the porting efforts?

@N9iu7pk:
On C201 with libreboot, Debian Stretch and kernel linux-image-armmp-lpae 4.8+76 from official Debian repos running the setup.sh script from Tails2Arm repo doesn’t work:

# sh setup.sh
setup.sh: 16: [: unexpected operator
setup.sh: 16: [: unexpected operator
setup.sh: 16: [: unexpected operator
setup.sh: 16: [: unexpected operator
setup.sh: 17: [: 0: unexpected operator
[2016-12-02 09:26:44] ABORT(0): Must run with root permissions!

Had to modify tailsDevFunc.sh before, change

function log() {

to

log() {

and

function abortOnFailure() {

to

abortOnFailure() {

and so on, otherwise it didn’t work:

# sh setup.sh 
setup.sh: 6: ./tailsDevFunc.sh: Syntax error: "(" unexpected

#38 Updated by intrigeri 2016-12-05 08:58:19

> What is the current status of the porting efforts?

I’ve not heard of any progress for months.

#39 Updated by N9iu7pk 2016-12-12 19:41:13

@LABRADOR: Seems sh instead of bash is used as shell/processor (unless #! /bin/bash) - could you please check, which shell is running/used?

#40 Updated by N9iu7pk 2016-12-12 20:09:55

intrigeri, redmine@labs.riseup.net

I could compile on an armhf platform (raspbery pi 2, rasbian) most of the packages, finally not all. I’m tired of debugging, even if it’s not clear, if rasbian could be the right platform.

As with issue Feature #11677 I also started running an arm debian instance on my rpi2 to run my tails build environment with debian (instead of rasbian). Additionally I’m setting up an dev environment to build (port?) tor browser on an arm platform.

#41 Updated by LABRADOR 2016-12-16 23:05:57

My bad, invoking

# ./setup.sh

looks good, the changes to tailsDevFunc.sh I mentioned above are not needed either. Will investigate further the next days.

Am I right that the approach towards a build environment you describe on https://github.com/n9iu7pk/Tails2Arm doesn’t qualify as reproducible?

FTR wrt the tcg issue: http://wiki.qemu.org/Features/tcg-multithread

#42 Updated by N9iu7pk 2016-12-17 12:24:23

@LABRADOR:

1.) Thanks for that tcg link, points out exactly the problem. I’ll take a closer look for a fix/patch/solution.

2.) Right, Tails2Arm is currently not intended to be reproducible. It ist just a documentation / help / repository to set up the arm environment.

#43 Updated by intrigeri 2016-12-17 15:22:13

> I could compile on an armhf platform (raspbery pi 2, rasbian) most of the packages, finally not all

I’m surprised that any custom package we ship doesn’t build on ARM.

Which packages don’t compile, exactly?

> I’m tired of debugging, even if it’s not clear, if rasbian could be the right platform.

I’m pretty sure that rasbian is not the right platform: Tails is based on Debian, and any port of Tails to ARM shall be based on some ARM architecture that’s supported in Debian.

#44 Updated by N9iu7pk 2016-12-19 09:16:58

> I’m surprised that any custom package we ship doesn’t build on ARM.
i.e. grub2 and all python based packages. It was a nightmare to identify all missing python libs. There’s one package issuing “no binary target”.

> I’m pretty sure that rasbian is not the right platform:
I’m too. But it was a very easy way to check wether building on a rpi / armhf directly/natively could bypass the TCG issue - since rasbian is based on debian and works well with debian apt sources. I worked on a quite scratched raspian.

Anyhow, there’s an armhf debian running on the rpi. That’s I’m currently working on.

#45 Updated by N9iu7pk 2016-12-28 21:48:16

The work I did to build an arm debian 8 image for my rpi2 is now documented, see https://github.com/n9iu7pk/Tails2Arm. No, the rpi2 is not the target platform but currently my arm play- and learnground.
From my point of view it is now clear, how to set up (debootstrap) a bootable arm debian and finally tails:
1.) abstract the 1st stage and hardware driven bootloader from an OS loader (i.e. 2nd stage loader as u-boot). I’m not sure about which loader could be suitable (requirements as open source, hardening against unattended/mad modifications and so on) For the moment, I’m working with u-boot.
2.) Build all tails specific packages. Currently my rpi2 is compiling/building, usually this takes a few days. If done, I’ll post the results (incl. logs of failed).
3.) Adapt the current live-builder process to the arm image builder. Currently I’m not sure about what exactly has to be done to set up an tails /boot after the 2nd stage debootstrap has been finisehd. It’s clear, that dpkg -i of all tails packages is probabely not the whole work.

#46 Updated by intrigeri 2016-12-29 09:58:22

> The work I did to build an arm debian 8 image for my rpi2 is now documented, see https://github.com/n9iu7pk/Tails2Arm.

Great!

Regarding building Tails-specific packages for ARM, and the issues you’ve met: note that you don’t need to rebuild the arch:all binary packages. By definition, the ones we’ve built already should be installable on any architecture (then some of them might not work on ARM, but that’s another matter). E.g. in https://labs.riseup.net/code/attachments/1395/20160531_buildState.txt I see that you were trying to rebuild tails-persistence-setup and whisperback: those you can safely skip. I hope this can save you some time… and headaches :)

Now, in order for our APT repository to actually make these arch:all packages available for some ARM architecture, we need to adjust our reprepro configuration, and then the right indices will be generated. Which (Debian) architecture would that be? Looking at https://release.debian.org/stretch/arch_qualify.html and the armel after Stretch (was: Summary of the ARM ports BoF at DC16) Roger Shimizu thread on debian-devel, it looks like the future of armel is at best uncertain, so this leaves us with armhf and arm64. Correct?

> 3.) Adapt the current live-builder process to the arm image builder. Currently I’m not sure about what exactly has to be done to set up an tails /boot after the 2nd stage debootstrap has been finisehd. It’s clear, that dpkg -i of all tails packages is probabely not the whole work.

Indeed, live-build does much more than dpkg -i when building an ISO from our source tree. I don’t know how much support it has for whatever may be ARM-specific (e.g. partition layout, boot loader, etc.). Note that we use our own fork of live-build 2.x, so make sure to look at the right codebase.

I’ve read that “[there’s] been a recent effort to add an EFI shim layer into modern U-Boot, which may allow for easier consistent boot support but there’s still issues to think about in terms of EFI variables etc.” — if that’s correct then we are in luck, and maybe a (GPT/EFI) disk created by Tails Installer from a Tails/ARM ISO can boot on modern U-Boot :)

#47 Updated by N9iu7pk 2016-12-29 17:18:15

> it looks like the future of armel is at best uncertain, so this leaves us with armhf and arm64. Correct?
Correct from my point of view. And aside from armel’s future, hard float could be at worst faster than soft float.

#48 Updated by intrigeri 2016-12-29 17:52:30

>> it looks like the future of armel is at best uncertain, so this leaves us with armhf and arm64. Correct?

> Correct from my point of view.

Thanks. So, once you’ll be at the point when you try building an ARM image from our Git repo, and you’re blocked by the lack of APT indices for armhf and/or arm64 in our APT repo, then I’ll make it so these indices advertise our arch:all packages.

#49 Updated by N9iu7pk 2016-12-30 12:39:20

Well! Means to rather adapt the live-builder to create armhf images than to try to build arm packages.

#50 Updated by N9iu7pk 2017-01-01 23:05:03

I decided to run lb build as far as possible to avoid to reinvent the wheel.

I’ve set up a build environment on my armhf platform running debian 8 jessie (according to tails.boum.org “Manual Build ISO” description):

- auto/build must be extended/modified to handle armhf/arm64 (< 10 lines of code)
- package isohybrid is not available for armhf (only arm64), live-build must be configured not to build an iso but an usb-hdd instead

lb clean and lb config are running on armhf without errors. And as far as I can see - proper/correct.

‘lb build’ runs but fails as expected due to missing armhf binaries
P: Running debootstrap (download-only)…
I: Retrieving InRelease
I: Checking Release signature
I: Valid Release signature (key id 221F9A3C6FA3E09E182E060BC7988EA7A358D82E)
E: Invalid Release file, no entry for main/binary-armhf/Packages

Further expected lb build problems:
- package syslinux-utils is not available for armhf/arm64, use syslinux-common instead, means lb_binary must be modified.

Anyhow, I’ll also document this as soon as possible on GitHub Tails2Arm

#51 Updated by intrigeri 2017-01-02 21:18:50

> I decided to run lb build as far as possible to avoid to reinvent the wheel.

Excellent :)

> I’ve set up a build environment on my armhf platform running debian 8 jessie (according to tails.boum.org “Manual Build ISO” description):
> - auto/build must be extended/modified to handle armhf/arm64 (< 10 lines of code)

Fair enough.

> - package isohybrid is not available for armhf (only arm64), live-build must be configured not to build an iso but an usb-hdd instead

/usr/bin/isohybrid is in the syslinux-utils package. I guess you mean amd64, not arm64, if I read https://packages.debian.org/jessie/syslinux-utils right.

> lb clean and lb config are running on armhf without errors. And as far as I can see - proper/correct.

Cool!

> ‘lb build’ runs but fails as expected due to missing armhf binaries
> P: Running debootstrap (download-only)…
> I: Retrieving InRelease
> I: Checking Release signature
> I: Valid Release signature (key id 221F9A3C6FA3E09E182E060BC7988EA7A358D82E)
> E: Invalid Release file, no entry for main/binary-armhf/Packages

OK, I think that’s soon the time when I should enable armhf and arm64 on our APT snapshots. Care to file a ticket about it, assigned to me, when you think it’s the right time?

> Further expected lb build problems:
> - package syslinux-utils is not available for armhf/arm64, use syslinux-common instead, means lb_binary must be modified.

Wait, do you need syslinux to boot on ARM systems? If not, see live-config’s —bootloader option. Not sure it supports what you need, but perhaps choosing GRUB would at least repair the build.

> Anyhow, I’ll also document this as soon as possible on GitHub Tails2Arm

A branch forked off our devel branch would be ideal.

#52 Updated by N9iu7pk 2017-01-03 14:40:01

> - package isohybrid is not available for armhf (only arm64), live-build must be configured not to build an iso but an usb-hdd instead
Yes, your’e right about the syslinux-utils package. xorriso can also generate hybrid iso images. During the research about isohybrid on ARM platforms I found a post discussing to implement isohybrid for arm64 platforms, that’s all.

> Wait, do you need syslinux to boot on ARM systems? If not, see live-config’s —bootloader option. Not sure it supports what you need, but perhaps choosing GRUB would at least repair the build.
Thanks for that hint. I currently do not know if syslinux is needed to boot on ARM systems (or “I” need that …). I only saw in lb_binary, that package syslinux-utils was requested but not offered for ARM platforms and syslinux-commons was the most best covering package. Anyhow I have to read more about …

#53 Updated by N9iu7pk 2017-01-03 16:57:23

See https://labs.riseup.net/code/issues/12111 to enable arm in APT snapshots

#55 Updated by N9iu7pk 2017-02-04 17:33:22

Additional next step:
- documentation, documentation, documentation -> github tails2arm

#56 Updated by N9iu7pk 2017-02-05 11:26:53

Debian is available for armhf and arm64 platforms. It is possible to build a tor browser for arm platforms, without modifications of the main build process or sources. I see no reason why the tails packages won’t compile for armhf or arm64 platforms. There’s at least one suitable 2nd stage boot loader - u-boot which supports efi boot. In general we should be able to plug anything together to a running tails on at least one arm platform.

But while getting the tor-browser running in a graphical UI with debian jessie I was faced with another general problem: The boot process and kernels. All arm platforms (most of them soc’s) I’ve seen meanwhile - including the mobiles - do not boot in the way as an intel or amd “pc” does. There’s no abstraction of 2nd stage boot loader from Operating system as we know it from BIOS or EFI and different OS-loaders. There’s no generic arm kernel for arm platforms as known for intel platforms. For each arm (soc) platform allwinner, broadcom, hardkernel etc. I was faced to use a prebuild kernel or to build an specific kernel from platform specific adapted sources.

Even though this seems to bee a serious (but solvable) technical problem, I personally see a two very huge advantages with this “Problem”:
1.) As less complex boot process architecture is, as more we can understand, harden an secure this process. Any further OS level security is based on that - an attac on 2nd level boot loader will compromise the the running OS as a whole / total. Take a look into an EFI boot section - much much much more complex, a much much much more bigger surface for attacs.
2.) Arm based SoC platforms are cheap, do have suitable cpu and ram ressources, are small (usb stick i.e. USB Armory) and do not consume too much power (usb power) - possible vision: A complete “machine” as soc on an usb stick running a tails instance from sd?

In consequence - if tails should be available as live OS for arbitrary arm platforms - we need

* a similar boot architecture as with “intel pc”

* or a 2nd stage boot loader that covers OS loader and generic kernel functions:

- is able to discover hw platform properties (armhf, arm64, chipset etc.)

- may choose between several kernels for each detected and supported platform
- and must advise that kernel to run with an armhf or arm64 boot partition

Do I missed anything or am I anyhow missleaded? Does anybody have any other ideas or any comments? Please give feedback!

#57 Updated by LABRADOR 2017-02-05 23:57:16

linux-image-armmp (and linux-image-armmp-lpae) from Debian Stretch is more or less generic. As the latter works on C201 (cf https://labs.riseup.net/code/issues/11677) the former should as well.
Probably it will be most reasonable (especially wrt maintainability) if Tails simply follows upstream in this matter.
(btw how do different kernels affect anonymity?)

What makes the kernel(-image) running on the aforementioned C201 currently unique is the inclusion of the device-specific dtb, but https://fedoraproject.org/wiki/Architectures/ARM/Chromebook#Rebuilding_ChromeOS_vendor_Kernel indicates that it’s possible to include several dtbs into one image.

Another question that arises is how chromebooks deal with standard GPT formatted disks (without CrOS extensions, cf. http://manpages.ubuntu.com/manpages/zesty/man1/cgpt.1.html) and how ordinary architectures deal with cgpt formatted devices - depending on that shipping a signed kernel parallel to an unsigned could be an option.

armhf should work on both, armhf and arm64, afaiu https://tails.boum.org/blueprint/ARM_platforms/#index4h2 (is this also true for kernels?)

#58 Updated by Dr_Whax 2017-02-06 21:54:36

Thanks for making so much progress so far, I think there are a lot of unanswered questions to the ARM world. For example, mainline kernel support seems to be a constant problem, will there be enough RAM for incremental upgrades, will ARM become a market with better support in the future?

I think for now, we have a more or less OK overview of what are the stumbling blocks that needs to be resolved.

I think the best thing that would help us for now is:

- Attempt an armhf port of any custom Tails packages that can’t build at the moment.

- Lobby/provide patches for an armhf tor browser bundle (not important for a technology preview)
- Attempt to package that in an technology preview ISO?

#59 Updated by N9iu7pk 2017-02-12 17:01:28

Thank you so much for your feedback, helps to stay on ground … ;)

Very good point: linux-image-armmp, I missed that. But as LABRADOR states “more or less generic”. And does not cover as much arm platforms as expected/desirable (i.e. Amlogic/hardkernel’s odroid’s C2 offers 2GB RAM …).

All in all I agree absolutely with LABRADOR. But I don’t expect to archive that “most-arm-kernel” in the near future, the arm landscape is still to volatile. It would be the most best option to contribute to debians armmp project/development. So it seems at last, that we meanwhile need a more “clever” (than uboot) boot loader (libreboot i.e.) that distinguishes the platforms into armmp supported and not supported ones.

Anyhow the way an amd/intel or C201 based on EFI or MBR boots is currently different from how an odroid or an olimex or a beageboneblack or a raspberry or usb armory boots: Their uboot’s aren’t designed to discover a boot medium (or boot partition on it) such as cd rom or usb, they all assume to have the bootable binaries on a fixed (mostly same) device.

I agree with Dr_Whax to first archive an armhf/arm64 ISO as technical preview. This includes

- armhf/arm64 compiled tails custom packages (see https://labs.riseup.net/code/issues/12111)

- research whether other boot loaders (i.e. libreboot) could/would be the better choice than uboot (boot medium/partition discovery, armmp/generic discovery etc.)
- And further work on tails live-build if we have armhf/arm64 tails packages to get an armhf/arm64 ISO.

#60 Updated by Kurtis 2017-02-14 17:29:16

I saw some chatter about Libreboot, so I wanted to post an update on the Libreboot on ARM work that is being done. Paul, the main ARM libreboot developer, has ported more devices to libreboot. The list can be found on his git repo here: http://git.code.paulk.fr/gitweb/?p=libettereboot.git;a=tree;f=projects/coreboot/configs/depthcharge;h=7a059aaa721c8eded351facaf588c90725fe21c0;hb=HEAD

I didn’t know what all the codenames were, so I search them all and made a list:

Veyron Jerry - Hisense Chromebook C11
Veyron Minnie - Asus Chromebook Flip
Veyron Mickey - Asus Chromebit CS10
Veyron Speedy - Asus Chromebook C201
Nyan Big - Acer Chromebook 13
Nyan Blaze - HP Chromebook 14

Paul told me that, on these devices, the main payload (depthcharge) allows chain-loading another payload, usually GRUB or SeaBIOS. He also said that the GRUB maintainer, Vladimir ‘phcoder’ Serbinenko, got GRUB running on at least one of these devices using this method.

Having a GRUB payload in Libreboot, at least on the x86 devices, makes it so you can encrypt /boot along with the rest of one’s disk and then decrypt /boot in Libreboot. It takes Full Disk Encryption to another level (Fuller Disk Encryption?). I haven’t heard of anyone making a fully encrypted Tails SD and then decrypting it in Libreboot, but it seems like this would be completely possible.

Anyways, I’m not sure if all of these devices can currently run Debian, but my assumption is that they all can. Most of the documentation I was able to find about these devices and Gnu+Linux were guides to install Arch.

The Chromebook Flip might be a good device to use to do testing on Handheld Tails, since it works like a regular laptop but also is very tablet-like, with its touchscreen. https://labs.riseup.net/code/issues/6064

Also, being able to run Tails on the Libreboot Chromebit would sort of blow my mind. It’s so tiny!

#61 Updated by intrigeri 2017-03-28 08:44:38

N9iu7pk: where’s your branch (forked off current Tails’ devel or feature/stretch branch) that builds an ARM image?

#62 Updated by N9iu7pk 2017-03-28 09:35:57

intrigeri: Sorry, I missed that. I’ll fork that branch as soon as possible.

#63 Updated by intrigeri 2017-03-28 10:00:18

> intrigeri: Sorry, I missed that. I’ll fork that branch as soon as possible.

Thanks :)

#64 Updated by N9iu7pk 2017-04-02 17:16:40

@Intrigeri: I registered at gitlab.com, added a pub. ssh key and requested access rights (ssh). But currently I still have no permissions at all (neither clone) using git ssh. Using git HTTPS I’m also not able to push my local branch to gitlab.com as upstream/remote. Seems I’ve to wait until I’ve got “access rights” (to push my branch).

#65 Updated by intrigeri 2017-04-02 17:48:33

> @Intrigeri: I registered at gitlab.com, added a pub. ssh key and requested access
> rights (ssh).

You need to click the “fork” button or similar: we don’t grant access to anyone (even core developers) to our Gitlab project, it’s only there to make it easy for you to fork our Git tree :)

#66 Updated by N9iu7pk 2017-04-04 16:10:31

Done / forked, see https://gitlab.com/N9iu7pk/tails. The current work on live-build isn’t yet submitted.
Due to description in “Submit your work” according larger work, I was focussed to a branch. Let me see, if I’m able to improve that description … :)

#67 Updated by intrigeri 2017-04-05 07:46:49

> Done / forked, see https://gitlab.com/N9iu7pk/tails.

What’s the branch we should look at, in this repo?

#68 Updated by N9iu7pk 2017-04-05 19:18:16

Branch named “feature/10972_TailsToArmv7”

#69 Updated by intrigeri 2017-04-10 15:15:05

> Branch named “feature/10972_TailsToArmv7”

This branch has no commit that our devel branch hasn’t. Is this expected?

#70 Updated by N9iu7pk 2017-04-11 08:47:50

Yes, due to I currently haven’t moved any work onlive-build into that branch.

#71 Updated by intrigeri 2017-04-11 09:23:10

> Yes, due to I currently haven’t moved any work onlive-build into that branch.

Aaaah, OK. So I’ll wait for you to do that before I work on Feature #12111.

#72 Updated by N9iu7pk 2017-05-01 18:03:37

Migrated; See https://gitlab.com/N9iu7pk/tails/tree/feature/10972_TailsToArmv7 and commit https://gitlab.com/N9iu7pk/tails/commit/b0c0a7ee3cfa694656dd119851f67e7e216871fc

This modified live-build runs upon tag 3.0-beta3 on an armhf platform exactly up to that point, at which armhf or arm64 binaries are requested:

…
I: Valid Release signature (key id 221F9A3C6FA3E09E182E060BC7988EA7A358D82E)
E: Invalid Release file, no entry for main/binary-armhf/Packages

Current lb configuration values are —bootloader isolinux and —binary-images usb-hdd

#73 Updated by intrigeri 2017-05-25 09:40:07

Thanks! Here’s an initial review:

• AMNESIA_CROSS_ARCHITECTURE="amd64 i386" ← why?
• You can drop PowerPC stuff, we have no plans to support that.
• I don’t know what the gnome-shell-extension-florence-indicator bits are for. If you merge the current feature/stretch branch into yours, you shouldn’t need that, do you?
• Please ensure you don’t introduce any trailing whitespace.
• Commit b0c0a7ee3cfa694656dd119851f67e7e216871fc does lots of different things, and some of them have nothing to do with “live-build extensions for armhf and arm64”: In general, we prefer atomic commits :)
• That commit introduces commented out code for “Only amd64 build systems are supported”. Please just drop it.
• amd64-unsigned is probably broken with current feature/stretch
• You’ll want to adjust LB_LINUX_FLAVOURS depending on LB_ARCHITECTURE, no?
• I suggest setting the best value for LB_BINARY_IMAGES automatically depending on LB_ARCHITECTURE, instead of leaving it to the developer to do it.
• “Woraround: Possible pitfalls in debian’s live-builder due to missing dir/files” seems very strange. It shouldn’t be needed in any clean build environment. What is it supposed to fix, exactly?

Otherwise, looks good! Thanks for working on it :)

#74 Updated by N9iu7pk 2017-05-25 10:37:51

I’ve been waiting (quite long) for a good review … thanks! I’ll continue the next days.

#75 Updated by intrigeri 2017-05-25 10:48:03

> I’ve been waiting (quite long) for a good review

Sorry; FYI 24 days for a review is not uncommon in Tails-land.
I’ve seen much worse in other projects, but still :/

> I’ll continue the next days.

:)

#76 Updated by N9iu7pk 2017-07-20 16:44:52

> Sorry; FYI 24 days for a review is not uncommon in Tails-land.
> I’ve seen much worse in other projects, but still :/

@intrigeri: Don’t be missleaded … I’m really glad to get a good feedback. And, as you can read, my periods are quite longer than 24 days … :D

Anyhow I reached the armhf/64 live-build’s tunnel. But with quite disillusioning results:

- I ve built on both, armhf and arm64 platforms.

- As binary I choosed usb-hdd with grub. ISO based (isolinux or isohybrid aren’t supported with debian 9)

- live-build does not support arm images (uboot, device tree blobs). But it’s possible to use flavour “armmp” to create that gerneric kernel.
- A complete boot partition was build. For what reasons ever tails packages aren’t installed and an *.img was not built.

It seems, that I should make smaller steps:

- build a pure debain 9 armhf/64 armmp live image first (usb-hdd, uboot)
* based on debian 9 live-build (not on tails specific)
* I expect, that debian’s live-build has to be extended to be able to build bootable arm images.
- THEN I’ll going to adapt tails extentions.

Meanwihile I received a pinebook, arm64 2GB fast ram: Does boot from microSD. Allwinner SoC, so armmp works (tested) in general. I’ll investigate as DrWhax did and reoprt also. All in all - suitable arm tails test platform!

#77 Updated by intrigeri 2017-07-22 06:33:29

> - (isolinux or isohybrid aren’t supported with debian 9)

What do you mean? What version of live-build are you using BTW?

> For what reasons ever tails packages aren’t installed

Presumably because we don’t provide arm* indices in our APT repo, even for arch:all packages.

> It seems, that I should make smaller steps:
> - build a pure debain 9 armhf/64 armmp live image first (usb-hdd, uboot)
> * based on debian 9 live-build (not on tails specific)
> * I expect, that debian’s live-build has to be extended to be able to build bootable arm images.
> - THEN I’ll going to adapt tails extentions.

Makes sense. Beware, though: the config tree layout has entirely changed at least once between live-build 2.x (that we’re using) and more recent versions.

> Meanwihile I received a pinebook, arm64 2GB fast ram: Does boot from microSD. Allwinner SoC, so armmp works (tested) in general. I’ll investigate as DrWhax did and reoprt also. All in all - suitable arm tails test platform!

Amazing!

#78 Updated by N9iu7pk 2017-07-28 20:15:58

Current Results:

- with debian 9 live-build current version we are able to build executable armhf/64 images but without bootloader => live-build must be extended at least for uboot.
- tails live-build should be adapted to the current debian live build.

intrigeri wrote:
> > - (isolinux or isohybrid aren’t supported with debian 9)
>
> What do you mean? What version of live-build are you using BTW?
If you choose —binary-image usb-hdd then lb does not create images with isolinux or isohybrid. I worked with debian 9 but live-build 2.x (tails). I’m not quite sure about that “pair” works well.

>
> > For what reasons ever tails packages aren’t installed
>
> Presumably because we don’t provide arm* indices in our APT repo, even for arch:all packages.
Seems so. I logged stderr and out, any package get was labeled with arm. Notice that I choosed chroot to build the image.

>
> > It seems, that I should make smaller steps:
> > - build a pure debain 9 armhf/64 armmp live image first (usb-hdd, uboot)
> > * based on debian 9 live-build (not on tails specific)
Worked partially. Anyhow isolinux/isohybrid binaries were missing in the chroot when xorriso tried to build the ISO image (and failed). Seems, that debootstrap didn’t installed that in the chroot. apt-get form inside chroot said “isolinux is installed” but the binary was not found. No idea why for the moment.
Anyhow I got a full rootfs (and kernels) I could boot with an external bootloader (uboot and suitable dtb. With armv7 armhf I could use flavour armmp (produced armmp kernels), with armv8 arm64 an aarch64 kernel was produced.

BUT - lb does not build uboot images (as expected). Anyhow I found on debians arm port pages debian installers for arm (i.e. for allwinner’s) which produce a bootable uboot image (tested with an olimex). So it must be possible, anyway, to extend lb to produce uboot images.

> > * I expect, that debian’s live-build has to be extended to be able to build bootable arm images.
> > - THEN I’ll going to adapt tails extentions.
>
> Makes sense. Beware, though: the config tree layout has entirely changed at least once between live-build 2.x (that we’re using) and more recent versions.
Yes, I’ve seen :(, smells for any work …

>
> > Meanwihile I received a pinebook, arm64 2GB fast ram: Does boot from microSD. Allwinner SoC, so armmp works (tested) in general. I’ll investigate as DrWhax did and reoprt also. All in all - suitable arm tails test platform!
>
> Amazing!
Tor works well. And the tor-browser works (ocompiled > 24h). And the tor-button. And partially the tor-launcher. Later more details.

#79 Updated by N9iu7pk 2018-02-04 15:25:11

Back again, found some time to proceed:

- please follow on https://gitlab.com/N9iu7pk/tails/blob/devel/gitlabwiki/HOME.md

- able to build pure debian arm64 images that can be booted with a rockchip brewed kernel; anyway not a mainstream debian kernel (or armmp one). arm64 or armmp kernels currently fail to initalize the rtc … :(
- currently trying to adapt the “old” tails live build to the latests debian live build … step by step.

#80 Updated by N9iu7pk 2018-02-18 13:43:35

@intrigeri: Need some help …

Regarding https://labs.riseup.net/code/issues/10972#note-77
>> For what reasons ever tails packages aren’t installed
> Presumably because we don’t provide arm* indices in our APT repo, even for arch:all packages.
Seems that might be a problem with debian’s lb:

• http://time-based.snapshots.deb.tails.boum.org/ has arch:all packages within the binary-amd64 and i386 tree nodes.
• ‘—architectures all’ or arch:all leads (as expected) to ‘E: Architecture(s) arch:all not yet supported (FIXME)’
• ‘—architectures amd64’ builds (as expected) an amd64 image, not running on an arm64 platform.
• ‘—architectures arm64’ or lb without that on an arm64 platform (host arch = build arch) leads to an error debootstap tries to fetch binary packages from binary-arm64 (lb bootstrap_archives binary)
  > N: Skipping acquire of configured file ‘main/binary-arm64/Packages’ as repository ‘http://deb.tails.boum.org devel InRelease’ doesn’t support architecture ‘arm64’

Current work is based on tails branch devel (not from a tag!) forked into a branch feature/10972_TailsToArmv7, see https://gitlab.com/N9iu7pk/tails/tree/feature/10972_TailsToArmv7. Is there a trigger to build arm64 binary packages and with wich repository are they available?

Anyhow:

• When resarching for projects or groups building debian based arm live images (i.e. kali) you can see, that either lb is used - with non-arm architectures - or that work is done “manually” NOT using lb (debootstrap, chroot, build kernels and uboot) within scritps (for exampe see https://github.com/offensive-security/kali-arm-build-scripts -> odroid c2 script).
• From a “bare” arm64 system (as rockchip rk3328 with 4gb ram, debian sid but rockchip kernel) you can build with debian’s lb an arm64 iso-hybrid image with lb - which can boot from a given uboot and rockchip kernel (mainline kernel (armmp also) sucks while init rtc of rk3328 soc …).
• SO - in general it is possible to build arm images with debian lb on debain’s binary package repositories and boot with on arm platforms - due to binary-arm tree nodes are provided i.e. for sid http://ftp.us.debian.org/debian/dists/sid/main/binary-arm64/

#84 Updated by N9iu7pk 2018-06-14 11:52:34

I’m still blocked … no access to a tails arm64 binary archive.
“arch=all” isn’t suitable, debians live buld lb expects explicit arm64.
currently no solution.
any ideas and help very wellkome!

#85 Updated by Kurtis 2018-10-23 20:51:12

Has anyone found a solution to the blocker articulated above?

#86 Updated by N9iu7pk 2018-11-11 15:22:23

Hi - I’v got neither any response nor any ideas how to solve that blocker. I would be pleased to get some contact to discuss that issue.

#87 Updated by Dr_Whax 2018-11-11 16:12:21

@intrigeri Does Tails want to host such an ARM64 archive? Is there anything that I can do to assist in this matter?

#88 Updated by intrigeri 2019-03-07 16:37:48

> I’m still blocked … no access to a tails arm64 binary archive.
> “arch=all” isn’t suitable, debians live buld lb expects explicit arm64.
> currently no solution.
> any ideas and help very wellkome!

Sorry for the long silence. It makes me sad that Tails, as a project, did not manage to keep up with your motivation and support your work here so far. I guess one reason is that those of us who have looked into ARM support for Tails have doubts wrt. what could realistically be the best outcome of this project (see our analysis. Still, I’ve personally promised to help on the infrastructure side and by and large, I’ve failed.

As far as I understand it, there are two APT-related blockers wrt. building a Tails PoC for ARM64:

Time-based snapshots

https://tails.boum.org/contribute/APT_repository/time-based_snapshots/

That’s Feature #12111. I’ve just posted a status update there (Feature #12111#note-14).

Now, given this ticket is mostly about reaching the PoC status, perhaps it’s not worth it yet to spend 600+ GB of RAID-1 mirrored SSD space, given it’s not a real blocker: you could hack the build system a bit so that it uses the Debian archive directly instead of these snapshots. For example, our devel branch always use the latest snapshot, which is — modulo a few hours — in the state of the current Debian archive.

What do you think?

Alternatively, the Puppet code that runs our time-based snapshots system is free software, so it’s doable to deploy it somewhere else than on Tails infrastructure, and point the build system there instead of http://time-based.snapshots.deb.tails.boum.org/. But I think it’s more work than pointing to the Debian archive directly.

Tails’ custom APT repo

https://tails.boum.org/contribute/APT_repository/custom/

On the one hand, I think I could easily enable arm64 there, and then you’ll should get all our custom arch:all packages (e.g. tails-greeter) for free. So far so good. I don’t mind doing that but I don’t think it’ll fix anything for you, as the hardest part of the problem will still be there for you to solve: you won’t get our arch:any packages, because we only build+upload them for amd64. So you’ll need to set up another custom APT repo and find some way to keep the arch:any custom packages, rebuilt for arm64, up-to-date in there. And once you do that, also uploading our arch:all packages to your own custom APT repo is no big deal.

So my take on this is that as long as you’re at the “let’s reach PoC status” stage here, you’d better point to your own arm64 custom APT repo instead of deb.tails.boum.org.

What do you think?

Later on, once you have a PoC ready and want to make progress towards production-ready state, then someone will need to find out how we can build+upload arm64 binary packages to our own custom APT repo, whenever we do that for amd64. To be honest, I doubt that someone will be anyone but you, and I’m not super confident there are good solutions, that don’t increase substantially the maintenance & development cost of Tails/amd64 (e.g. we currently build our own Thunderbird and I don’t see us doing that in a QEMU VM on amd64 hardware, so we would need trusted arm64 hardware maintained by our sysadmins). Similar issue for Tor Browser, possibly with quite some porting fun on top. I don’t mean to be a downer but I want to be honest with you and make sure you have the next, hard steps in mind, before you decide to commit further time & energy on yours to this project :)

#89 Updated by intrigeri 2019-03-07 16:39:02

Hi @Dr_Whax,

> intrigeri Does Tails want to host such an ARM64 archive? Is there anything that I can do to assist in this matter?

See my above answer: I suspect that N9iu7pk might need some help to run some APT stuff elsewhere than on the Tails infra.

#90 Updated by Kurtis 2019-03-18 23:56:32

Tor Browser was successfully built for ARM!

http://ea5faa5po25cf7fb.onion/projects/tor/ticket/12631#comment:25
https://wiki.raptorcs.com/wiki/Porting/Tor_Browser

#91 Updated by amp 2020-03-27 12:04:46

intrigeri wrote:
> Later on, once you have a PoC ready and want to make progress towards production-ready state, then someone will need to find out how we can build+upload arm64 binary packages to our own custom APT repo, whenever we do that for amd64. To be honest, I doubt that someone will be anyone but you, and I’m not super confident there are good solutions, that don’t increase substantially the maintenance & development cost of Tails/amd64 (e.g. we currently build our own Thunderbird and I don’t see us doing that in a QEMU VM on amd64 hardware, so we would need trusted arm64 hardware maintained by our sysadmins). Similar issue for Tor Browser, possibly with quite some porting fun on top. I don’t mean to be a downer but I want to be honest with you and make sure you have the next, hard steps in mind, before you decide to commit further time & energy on yours to this project :)

Hello,

Even if armhf/arm64 don’t become officially supported architectures by Tails it would still be very useful to have the (manual) steps to build ones own image.

E.g. currently I have access only to arm64 hardware and no plans to change that. This makes it impossible for me to run Tails. On the other hand I would be willing to let my PINE A64+ work on building an image / updates, even if it might take a week or so.

#92 Updated by N9iu7pk 2020-03-27 22:17:49

Hi all. I’m sorry I was offline for a long time. I was a little frustrated and demotivated. Anyhow, my very first approach in the beginning was to build up an own, separate repo for all Tails specific bundles. Mainly because Tails is based on Debian which is (except a generic kernel) meanwhile fully enabled for arm64, including gnome3. There is absolutely NO need for a full blown Debian repo to build tails on arm:

- The very first approach was to build up all Tails packages from sources (compile and build deb packages) directly on a target arm64 platform - failed.
- The second approach was to update the outdated Tails live build. That was faced with two problems

• on arm there’s neither a generic kernel nor generic boot process available.
  Also the arm tools building an ISO where not available. I could build “normal” arm64 debian
  distributions up to that point, a bootable medium should have been build.
  Probabely that would not have been a KO criterion.
• arch all didn’t worked on Tails repos

- Apart from these problems arm platforms offering a very interesting but sneaky property: There is no BIOS or EFI, there is by definition just a hard wired first level boot loader, nothing else. Hard to compromise. The remaining system configuration and boot stack comes with a removable device which might be checked very easy for modification regarding configuration and boot stack. And - there’s no trace on a device if the boot device has been removed (mostly a sd or emmc cards), since there’s usually no other medium (except small spi flashes). But this is also very sneaky: Each fucking arm device needs its own dtb, requires adaptions for its hardware in the 2nd level boot loader (core/libreboot, uboot) and needs some kernel patches. For example the only arm device I’ve seen, that’s running Debian with an unpatched kernel was - USB Armory. Booting a live distribution? From USB? Nice nightmare: Mostly that devices aren’t dedicated to boot from USB unless you boot first a 2nd level bootloader from a non USB device that loads a kernel that boots from USB … not a suitable way. There is a generic kernel project but it’s still a very long way until there’s a generic boot process for arm devices.

Anyway - next attempt! This time I’d like to discuss first possible steps:
1. Target platform still arm64 and architecture aarch64.
2. In the first step, just build an Tails image - which is booted “external” from the platform specific kernel / boot stack.
An image - with e.g. Debain Buster - is very easy to build.
The point is to apply all Tails specific “customizations”, so that it runs as live instance without changing its image.
I’m still not very familar with all that packets / customizations.
3. Setup of boot stacks for arm64 platforms
There’s a limited number of platforms/SoC suitable (Open architecture, RAM, CPU - and low price!) to run Tails and OpenSource kernel patches. For example: The PINE A64+ or Rock64 (PineBook) which all boot from sd cards.
For 3 of the most popular devices boot stacks could be build.
For the remainig devices … ?

Means:

- It would be very helpful to understand, what Tails specific packages are active and must be installed (live build once helped me to understand some parts).

- If the full image build process is clear a PoC could be started: Based on a Debian Buster. If there’s a arm64 binary repro it would be fine, otherwise missing package by package must be compiled and packed (deb) for arm64.
- It’s not clear, whether a live build will be required at the end. Probabely deb-bootstap would be suitable.

Any feedback? Any help?

Best regards to all!

#93 Updated by anonhat 2020-04-06 02:37:05

There seems to be quite a bit going on here, and it’s difficult to see specifically what direction this project is going in. Regardless, I think looking into the current Debian and Arch builds for ARM (in particular aarch64, since it tends to be implemented in a more “standard” way like x86 systems are) would be a good starting point regarding making a possible generic kernel with all the drivers/hardware support necessary to run on popular ARM boards. It might also benefit this project to have its own, separate domain/site for development, since this will likely require substantial developer communication and infrastructure beyond what the Tails issue tracker provides. I’d be willing to foot the bill for that, if necessary.

#94 Updated by N9iu7pk 2020-04-10 17:32:37

> It might also benefit this project to have its own, separate domain/site for
> development, since this will likely require substantial developer communication
> and infrastructure beyond what the Tails issue tracker provides.
Exactly that is one very important point. A subdomain is not the point, more something like github/gitlab (git repo, tasks, wiki pages etc.) but I’d rather entrust code, docs and discussions other platforms (riseup, immerda or probabely salsa.debian.org): risup seems to be suitable for discussions and docs but not for code, salsa is perfect as git repo and but not for collaboration (wiki or docs) …

I’d prefer

- git rep at salsa.debian.org (or immerda.ch)
- wiki at immerda.ch

Any other ideas?

#95 Updated by RooktheObserver 2020-05-06 22:23:44

Just recently I have come across the RaspPi 3 having a firmware that utilizes UEFI. It also has a HWRNG internally, which makes it a good candidate for such a project.
https://github.com/pftf/RPi3
which circumvents the board-specific boot process a bit & makes available USB as a boot device. I use a NanoPC-T4 with a rockchip 3399/mali combo & its EMMC flash process allows for USB to provide a flash image or backup image, while a uSD card is inserted with the FriendlyELEC eflasher.
I have been poking around for a TAILS-like system for my NanoPC and created an account here so I could suggest the above ideas since it seems like this project is still active.
Thanks