Hi there! TLDR; Not much has changed in the last 7 years probably. I think that thanks to the Asahi project Tails will be able to run on Apple Silicon on stock Debian packages in the foreseeable future (and with far better support than x86_64 Apple has received until now). Maintaining a unified arm64 image might be more of a burden than maintaining separate arm64 images, if at all possible. I merged the 6.0~rc1 changes into my branches and rebuilt and uploaded the generic arm64, Apple Silicon and Raspberry Pi Tails images.
Let me start by saying that my experience with arm hardware is limited to Apple Silicon and Raspberry Pis, so I don't really have an overall picture of how things are done in the arm world. Nonetheless, my impression (and the general consensus among those who actually develop for arm, AFAIK) is that every vendor still does their own thing and usually doesn't take the time to build common standards for interoperability. For sure this is the situation I found when building those images. Let me give you some examples by going into some technical detail. *** Booting + firmware *** The plain "wip/arm64" image in the folder I shared is a straightforward translation of Tails from x86_64 to arm64 except for some quirks, e.g. the directory layout of the initramfs (which is different on arm64 Debian) or the absence of unneeded software such as syslinux. This image boots with UEFI and runs on standard Debian packages (except for those which I rebuilt from the Tails repository). In particular, it can be run as a VM e.g. using native KVM, and probably by emulating an arm64 VM on x86_64 too. It won't USB-boot on neither RPi nor Apple Silicon though, first and foremost because those do not support UEFI out of the box (this is not the only reason, though, more on this later). How do the RPis and arm64 Macs boot? The former actually use different mechanisms for different models (just to keep things simple, you know), see e.g. https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#raspberry-pi-boot-modes and the following sections, but also https://www.raspberrypi.com/documentation/computers/configuration.html#the-boot-folder for details on the firmware files. The bottom line is, if not configured otherwise, each model does its thing and ultimately loads a kernel with a specific file name from the boot partition (some models load the same kernel, others don't), together with a similarly-named initramfs. In that partition you thus need to include some /{kernel*,initrd*} files, plus firmware files. Also, not all arm64 models can boot from USB (RPi4 and 5 can, I can't remember which others can or cannot), and I have not attempted booting Tails from an SD card. As for the arm64 Macs, as I wrote in my first email, they don't support booting from external media. However, the (internal) bootloader used by Asahi Linux - which actually is a chain of bootloaders, see e.g. https://github.com/AsahiLinux/docs/wiki/Distro:Boot-process-guide - is actually able to boot from USB with UEFI, and can be installed stand-alone. So if your user is willing to waste ~ 3GB of disk space on a separate partition just to be able to boot Tails, they are good to go. And if they already have an Asahi Linux distro installed, they actually already have the bootloader/chain installed. Interestingly, the on-disk files (the kernel, initramfs and firmware) needed to boot a live OS on RPi and Apple Silicon do not conflict with each other: they can be included side by side. For the record, while you do need to include the RPi firmware in the image, on Apple Silicon that comes preloaded by the Asahi bootchain. No proprietary Apple firmware needs to be included in the image. I will mention here that there's a chance that the RPis <= 4 could also be booted via GRUB/UEFI, either by first loading U-Boot and then grub (U-Boot seems to support RPis <= 4, see e.g. https://hechao.li/2021/12/20/Boot-Raspberry-Pi-4-Using-uboot-and-Initramfs/, and U-Boot is able to load grub-efi), or by using stuff like that in https://github.com/pftf. I didn't try any of those mainly because I own a Raspberry 5, which is not supported (yet?) by those projects. *** The kernel and initramfs *** It is likely that most bare-metal arm64 platforms Tails wants to support will need a dedicated kernel in order for them to work properly (or at all), at least in the near future. This is certainly true at this very moment in time for Apple Silicon: these machines will not work with the current stock Debian kernel, and Linux's support for Apple Silicon - though quite mature at this stage - hasn't been fully upstreamed yet (the main repo lives at https://github.com/AsahiLinux/linux), even if this is the ultimate goal of the Asahi project. I was recently told by the Debian Bananas team that official support for Apple Silicon will likely only come from Debian after the Asahi patches have been merged upstream. As for RPis, the Raspberry kernel repo (https://github.com/raspberrypi/linux) seems to contain its own patches, so I believe the situation is similar (except for the lack of an upstream-first policy). Also, there are different flavours of the Debian kernel for different RPi models. In both cases, the kernel binaries/packages are not present in the Debian archive: Raspberrys use their own repository, while as I said the Asahi kernel is not even packaged for Debian yet. Incidentally, this is one of the reasons (asides from work-related stuff) why it took me so long to write down this answer: packaging the Asahi kernel for Debian (both Bookworm and Trixie/testing) is what I've been trying to do lately. It has been a pretty challenging task mainly due to the Asahi kernel needing a full Rust(+LLVM) toolchain for the GPU drivers, pinned to nearly-specific versions which are not present in the Debian archive for a given distribution. Should you be interested you will find the results at https://gitlab.com/debian-asahi-nc (source code) and https://deb.noisycoil.dev/ (source+binary packages). Now, let's suppose that the Debian packaging of the kernels for the different arm platforms was in a state acceptable to Tails. Then it may be possible to include each of these kernels in the Tails image (perhaps from the respective custom repositories). This can certainly be done with Apple Silicon + RPi, since as I said these platforms use different, non-conflicting boot mechanisms, and they would automatically load the kernel they need. As for other platforms, whether their specific kernel (if any) could be included in a unified image depends on the specific platform and boot mechanism. We can't really say in general. One caveat is that the initramfs that goes with each kernel usually needs platform-specific content. Some tweaks may be needed to Debian's initramfs-tools to make sure that the initramfs's are built not only correctly (this is usually taken care of by platform-specific packages) but also, most importantly, interoperably. *** User space software *** I believe this is where the true headaches would start with unified arm64 images. The Asahi project is an example in interoperability. If we exclude the Asahi kernel and Mesa drivers, Linux already only needs a single extra package (asahi-scripts, needed to properly build the initramfs) to run on arm64 Macs; a couple more are needed for enabling the speakers. All of these already are in Debian testing (https://wiki.debian.org/Teams/Bananas). Once the kernel and Mesa drivers are fully upstreamed and packaged, Asahi will be able to run on stock Debian packages, meaning that the only thing Tails will need to do to support Apple Silicon is teaching its users how to install the Asahi bootloader (this just can't be avoided). En passing, I'd like to note that, in my opinion, thanks to the Asahi project Linux's support for Apple arm64 platforms is far superior than for x86_64. This will likely translate to Tails if ever it decides to support Apple Silicon at all. As for the other arm64 platforms, as you already noticed things don't usually work like Asahi. For example, take the main component of the Raspberry debian repository, https://archive.raspberrypi.org/debian/dists/bookworm/main/binary-arm64/Packages (arm64 Bookworm), which I'm using for the RPi builds. This contains around 1k custom packages. Which of those can be replaced with their stock Debian counterpart? Hard to tell. It is easy to guess that some (if not many) of those packages are RPi-specific and can't. Also, some of those will probably conflict with other hardware. Thus while building a single image with multiple non-conflicting kernels and firmware may be viable, it would be quite unmanageable (if not impossible) to do that without software conflicting is user space. All in all, I believe supporting a limited number of arm64 platforms (I agree with David that Apple Silicon, Raspberrys and ChromeBooks should be the primary targets) could be less of a burden for Tails, if not the only viable option. If this is the objective (I mean in principle; I do understand you are not currently planning to support arm64), then I believe we're not far away from Tails on arm64. I mean, the images I built already boot and connect to the internet via Tor =D. Altough Tails is (very) much more than that, I'd still call that a good start. Again, I think the Tor Browser currently is the main blocker. By the way, I just merged the 6.0~rc1 changes (current devel branch) into my branches and rebuilt all three images. You will find them in the usual mega.nz directory. In the meantime I also fixed tails-get-bootinfo not working on RPis and making initramfs-restore crash. OnionShare is unfortunately still not working on that platform, and I currently do not know why. Best, NC Feb 1, 2024, 14:09 by ano...@riseup.net: > Hi, > > First of all, very impressive work! Damn! > > On 21/01/2024 23.04, NoisyCoil via Tails-dev wrote: > >> In principle, making a universal arm64 image could be possible, but >> asides from the firmware (storing different firmware for different >> platforms on the same image may be feasible), the software and >> drivers may need different tweaks for different platforms. Quite a >> few Debian-based distros are providing different arm images for >> different platforms. >> > When we looked into Tails on ARM [0] around 2017 what I quoted above was what > at least made me give up. For instance, the Chromebook [1] I was > experimenting with needed specific kernel patches (that IIRC breaks stuff for > other ARM systems) in order to boot, and a proprietary graphics driver if you > wanted any kind of hardware acceleration or nice screen resolutions. Looking > at other systems it seemed like basically all of them required similar > model-specific kernels/firmware/drivers/tweaks/fixes, and all this was also > not documented really, so you had to reverse engineer this knowledge. > > [0] https://gitlab.tails.boum.org/tails/blueprints/-/wikis/ARM_platforms/ > [1] > https://gitlab.tails.boum.org/tails/blueprints/-/wikis/ARM_platforms/Acer_Chromebook_R_13_CB5-312T > > Is it your experience that the situation for ARM systems is basically the > same now, 7 years later? > > Another thing that demotivated me was that the "ARM world domination" > scenario, where Intel/AMD platforms would become niche and ARM dominat, that > I semi-expected at the time, doesn't seem to be happening. I wonder if even a > smaller ratio of laptops sold today have ARM than around 2017 (at least I see > many Intel Chromebooks). But as long as Intel/AMD remain ~dominant it is hard > for us to justify spending resources on other, less common platforms. > > And as for supporting Apple Silicon, well, we barely are able to support > Apple Intel systems at the moment. Given our scarce resources we > de-prioritizes Apple hardware, feeling OK with it due to the assumption that > if you already have Apple hardware (Silicon or not) you are affluent enough > to most likely already own an AMD/Intel-based computer that can run Tails, or > afford to buy a cheap one. > > I say none of this to in any way dissuade you, just to give you my > interpretation of the context of where the Tails project stand on these > topics. We constantly re-evaluate our positions, so if some data shows that > other platforms are relevant for our users and someone can do the work for us > or fund us doing it, then Tails on e.g. Apple Silicon and some select ARM > platforms could become a reality. > > Again, impressive work! > > Cheers! > _______________________________________________ > Tails-dev mailing list > Tails-dev@boum.org > https://www.autistici.org/mailman/listinfo/tails-dev > To unsubscribe from this list, send an empty email to > tails-dev-unsubscr...@boum.org. > _______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
