Re: [Tails-dev] Tails for arm64 (with support for Apple Sili…

Delete this message

Reply to this message
Autor: noisycoil
Data:  
Dla: N9iu7pk, The Tails public development discussion list
CC: NoisyCoil via Tails-dev
Temat: Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)
Hi N9iu7pk!

Good to know you managed to build the image, you're the first person to confirm it works! While I finish working on some quite exciting new features (I'm almost there but need to polish some stuff), let me give you some advice and provide some comment.

- If you are running the image on a RPi5, then you could as well build it there (unless you have a good reason not to). This is what I am doing right now, as natively building Tails on a 8GB RPi5 is MUCH faster than building it on a 16-core 32-threads 64GB AMD machine. I'm talking 1.5hr tops (often less) on RPi5 vs. even 13 hrs on amd64.

- What you're saying about debian-security sounds weird to me. I never had issues accessing the debian-security repo via http, neither in general nor during Tails builds. E.g. a plain `curl http://deb.debian.org:80/debian-security/dists/bookworm-security/Release <http://deb.debian.org/debian-security/dists/bookworm-security/Release>` works.

- Yes, you picked the right branch. I am working on rebasing everything on stable (with new features), so a big rebase is coming soon, but the new branch names will still be wip/arm64, wip/asahi and wip/raspi. 'stable' and 'devel' are just (probably non-up-to-date versions of) Tails' regular stable and devel, with no arm64-related changes.

- I never had certificate/sources issues, but I've been building on the stable branch (see above) for at least a couple of weeks now, so it may be that something broke in the meantime on the old devel-based branches.

- arm64 builds are not supposed to work on x86_64 without any build options. In theory not having build options on x86_64 machines would simply build an x86_64 version of Tails. However,

    1. the Asahi and RPi branches need changes that are so relevant (e.g. to the apt sources) that would require a big re-write of auto/config to maintain compatibility with x86_64 builds, and I didn't want to do those re-writes arbitrarily (i.e. without the prospect of actually merging those changes)

    2. x86_64 builds on the arm64 branches could be broken in other ways, e.g. by the packages in config/chroot_local-packages, or even because I overlooked something while enabling cross-builds. Before uploading the stable-based branches I'll try and see if something needs to and can be fixed in this respect (in theory the wip/arm64 branch could build regular x86_64 images). In any case, keep in mind that the arm64 changes are nowhere near to be merged (neither from my part nor from the Tails side), so it's fine if they break x86_64 builds for now, so long as they don't do so intentionally, and if the breakage is fixed when possible

- systemd-sysctl.service failing: this is a known (by me) issue. It is due to the "CONFIG_ARCH_MMAP_RND_BITS_MAX" kernel configuration variable. For Debian's standard arm64 (and amd64) kernel it equals 32, for Asahi 16k pages kernels it's 31, it's 30 for the 4k pages 64-bit RPi kernel, and it's 24 for the RPi5 16k pages kernel. systemd-sysctl.service tries to set `mmap_rnd_bits` to 32 as specified in /etc/sysctl.d/mmap_aslr.conf, so it fails on every kernel except for vanilla Debian's standard arm64 kernel (i.e. on the wip/arm64 branch). I've already fixed this in the Asahi images (not pushed yet) but not in the RPi ones. Thanks for letting me know so I could look into it! A fix will be coming soon.

- I noticed the freezing issue too. It only happens on RPi, never saw that on Apple Silicon nor on arm64 VMs (wip/arm64 branch). Also, it doesn't happen always. This makes me think the freeze may be due to some sort of race condition triggered e.g. by RPi being overload at boot time. Also it looks like this: https://gitlab.tails.boum.org/tails/tails/-/issues/20227. If it was already fixed in mainline Tails, then the fix is probably not merged to my public branches yet (but will soon be).


I agree that a double image (two squashfs) is very appealing, but making it would require a full re-write of the image-building process, so I'm not sure I'm willing to waste time on that at this time. I explicitly talk about waste not because it is useless in principle (it is not, of course), but because the changes would be so radical that making them arbitrarily, without the involvement of Tails maintainers and/or without actual plans for merging them, would essentially amount to a waste.

Instead, for the time being, I'd like to make sure that everything works properly and that whatever needs to be upstreamed is upstreamed. Do I hear official support for the Tor Browser on arm64 (https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_requests/920)? Do I hear Tails automatic test suite?

More to come soon.

NC