Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[NoisyCoil via Tails-dev]

Dear all,

Congratulations on the new release! As usual, I uploaded the arm64 builds to 
MEGA.

The only relevant news this month is Tails Asahi v6.4 comes with Linux v6.8.11, 
which means that for the first time Tails is on par with Fedora Asahi in terms 
of Apple Silicon hardware support. Concretely, there's now support for speakers 
and HDMI video, and more generally for whatever is listed here: 
https://asahilinux.org/fedora/#device-support. Note, however, that I don't 
possess the hardware (nor the manpower!) to actually test that everything works 
as intended. It does as far as my tests go, but, in case it doesn't, that's 
probably on me, not on the Asahi devs :-)

Cheers,

NoisyCoil


P.S.: I had to tweak one step definition ("When /^I open a new tab in 
the(.*)$/") so that the cursor is moved out of the way after opening a new 
browser tab, because after upgrading from Linux 6.6 to 6.8 the cursor suddenly 
started to be shown on the screen during at least one of the scenarios, 
obstructing the "new tab" button and making it impossible to recognize 
"TorBrowserNewTabButton.png". I have not fully debugged this yet, and since you 
wouldn't be able to reproduce it anyway I won't open an issue at this time.
___
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.

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[NoisyCoil via Tails-dev]

Dear all,

Congratulations on the 6.3 release! The arm64 builds are in the usual MEGA 
directory; I pushed the 6.3-{arm64,asahi,raspi} tags (6.3/{arm64,asahi,raspi} 
branches) to my repository a couple of hours ago.

Tails Asahi v6.3 comes with Linux v6.6. This is the latest version of the 
kernel which has been packaged for Debian, and for which the Asahi patchset 
supports speakers on most Apple Silicon machines. Backporting the Asahi audio 
stack to Bookworm is WIP (it's been uploaded to testing/sid only in the Debian 
archive), so audio is not enabled yet on Tails Asahi v6.3, but it will be in a 
coming release.

Other than this, I am happy to share that my first patchset for porting the Tor 
Browser to linux-arm64 has been merged upstream. A second patchset is currently 
being reviewed, and a third one will complete the series and bring full support 
for cross-building the Tor Browser for arm64 from x86_64. This doesn't mean 
there will be official arm64 builds immediately, but still, their being able to 
build the browser on their infrastructure is the first step in that direction.

Best,

NoisyCoil
___
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.

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[NoisyCoil via Tails-dev]

Dear all,

Congratulations on the 6.2 release. You will find its arm64 port in the usual 
MEGA directory. The images are built on my 6.2-{arm64,asahi,raspi} tags 
(6.2/{arm64,asahi,raspi} branches). This time around the only big changes 
involve the Raspberry images. Let me take a step back first, I'll come back to 
RPi in a moment.


Recently, I came across this issue: 
https://gitlab.tails.boum.org/tails/tails/-/issues/20347. Starting from v6.6 of 
Debian's linux kernel, the kernel modules will be compressed using xz, and as a 
result two build-time hooks (plus one initramfs hook) will misbehave. Now, the 
failure of one of them, 80-block-network, has security implications: since 
80-block-network is unable to find the network drivers' modules anymore (they 
are renamed from *.ko to *.ko.xz), it fails (silently!) to populate 
/etc/modprobe.d/all-net-blocklist.conf - that is, the blocklist used to disable 
networking at Tails's boot. As a result, neither network blocking at boot, nor 
e.g. disabling networking using the Welcome screen, work. Patching this is 
quite simple, and I've already submitted a MR 
(https://gitlab.tails.boum.org/tails/tails/-/merge_requests/1499). To be very 
clear, x86_64 Tails uses linux 6.1, so it is not affected by this issue.


On the other hand, it so happens that the Raspberry kernel uses module 
compression already in linux 6.1, which is currently in the arm64 images. Thus 
the Raspi 6.1 Tails images are affected by this security issue. To fix it in 
Tails/RPi 6.2, I've already merged !1499 to all my branches (together with the 
uBlock patch which was the subject of previous emails), including those (arm64 
and asahi) which do not use module compression (yet).


For the record, the test suite would have detected this issue easily. In fact, 
it actually did: I came across it while testing (unreleased, unpublished) 
Tails/Asahi builds with linux 6.6 in place of the currently installed 6.5. 
However, the Raspberry images use a non-virtualizable kernel, so I can't run 
the test suite on them. As I said previously, this is unfortunate since the RPi 
images include a decent number of custom Raspberry packages which - as you can 
see - makes testing a necessity.


Best,

NC


P.S.: I believe that an earlier version of the Asahi images was also affected 
by the same issue: it used a non-Debian kernel with compressed modules which 
would trigger the hooks' failure. At that time (before 6.1) I was not using the 
test suite yet. Avoiding these kind of things is the main reason why I switched 
to my own kernel builds, which are just the regular Debian kernel with the 
Asahi patches.
___
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.

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[NoisyCoil via Tails-dev]

Hi n9iu7pk,

Good to know you were able to build the images! The nvme will surely help, I/O 
is terrible on RPis (but then, this is expected).


So first of all, no, you don't have new images to compare the shasums at the 
moment. I think from now on, unless there are major new features from my part 
which merit early sharing, I will only upload pre-built images on new Tails 
point releases (uploading takes quite some time and a single upload of 2x3 
images takes away around half my available space).


In general, only images built on tagged commits are reproducible. In case you 
don't know (if you do I apologize, I have little knowledge of the Tails 
community), when the commit is not tagged, the /etc/apt/sources.list and 
/etc/apt/sources.list.d/bullseye.list files contain entries like

```
deb http://time-based.snapshots.deb.tails.boum.org/debian-security/2024041403 
bookworm-security main contrib non-free non-free-firmware
```

with last-snapshot timestamps which change multiple times a day (4, I believe). 
However, I must have been lucky enough to start a new 6.2/arm64 build while the 
debian-security snapshot was the same as yours so I got the same sha256sums as 
you! Not so lucky with asahi and raspi, which you had built earlier and I built 
later. Nonetheless, I compared today's contents with yesterday's and can 
confirm that the only difference is precisely those timestamps.


"tests: on raspi image -> 206 fails, 1460 skipped, 342 passed -> 
reproduceable." As you can see, most of the tests are skipped: the raspi image 
never boots (it cannot be virtualized), so it fails early and skips the other 
steps. arm64 and asahi, on the other hand, should work.


Thanks for the estimate. I initially thought that Tails was snapshotting the 
whole debian archive, but soon realized that they don't need to do so since 
when booted the images use the actual live debian archive instead of snapshots. 
Making arm64 snapshots would be far less costly than I initially thought 
(nonetheless, I have no plans to set up my own: the images already contain far 
too many binaries provided by myself!)


Best,

NC


___
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.

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[n9iu7pk]

Hi noisycoil,

good news: could now build all images on 6.2 branches :) and could also 
run tests -> my nginx setup was faulty (typo). Meanwhile I've upgraded 
my PI5 with a nvme pcie ssd (N04 pcie board on top) -> run's noticeable 
faster :)


Some results:

- "how much space the amd64 Debian snapshots in use by Tails take up?" 
Roughly estimated along the apt-cacher volume after building all images: 
1714316 KB /var/cache/apt-cacher-ng


- tests: on raspi image -> 206 fails, 1460 skipped, 342 passed -> 
reproduceable.


- sha265sums (do we have images/builds to compare?):
c3b7251259df11ef71a559164a6d4d0f23e322fb58220ca6c4207e320bd66107 
tails-arm64-6.2_arm64@8928015f41+sta...@fe2dd74d4d-20240414t1502z.apt-sources
7a3843bbd2696e98df715025a9cb93fc8ddf4ff57d011d1368b7cd80356c41a3 
tails-arm64-6.2_arm64@8928015f41+stable@fe2dd74d4d-20240414T1502Z.build-manifest
6bc699eb40d4eb9eca1450fc9eb8eb1d215fbe76cf5c7a80689ba018457dfd2e 
tails-arm64-6.2_arm64@8928015f41+stable@fe2dd74d4d-20240414T1502Z.buildlog
e0efcb0d0590363e726aed0698c03aece54334f680400764ab14719221165e5e 
tails-arm64-6.2_arm64@8928015f41+sta...@fe2dd74d4d-20240414t1502z.img
d9c721096f08eddc4a50c7cc79a756abbe39dbc0cad502b8fb9020717f4c4782 
tails-arm64-6.2_arm64@8928015f41+sta...@fe2dd74d4d-20240414t1502z.iso
191c45f6d51ab741443e7eeeff03c832c0af12fb448bcdb9a77ba109fa9e2fc0 
tails-arm64-6.2_arm64@8928015f41+stable@fe2dd74d4d-20240414T1502Z.packages
23369a3e276a322d794e5ef09a1e74c25849ad82741564fba18045702b8e395b 
tails-arm64-6.2_asahi@7345947cc8+sta...@fe2dd74d4d-20240414t1418z.apt-sources
022aefd49fc78699a584cbfc697806d90280125541f46a08dede06c06df4e9ae 
tails-arm64-6.2_asahi@7345947cc8+stable@fe2dd74d4d-20240414T1418Z.build-manifest
93f1e07f3fae5796604a780d2d87166e90eee6167306fb68177e93663903874f 
tails-arm64-6.2_asahi@7345947cc8+stable@fe2dd74d4d-20240414T1418Z.buildlog
b33178d88094ff3b83970f8e7497fe2b14110ef95d4d42cf34da787967254ed0 
tails-arm64-6.2_asahi@7345947cc8+sta...@fe2dd74d4d-20240414t1418z.img
1a07ed1050417460ff7a16a62c854330ea510d73771c19968706b3444cabbe3d 
tails-arm64-6.2_asahi@7345947cc8+sta...@fe2dd74d4d-20240414t1418z.iso
9afab6262eef404e73a28d28338752f3543c026aab9341aefeb322109d34a6b0 
tails-arm64-6.2_asahi@7345947cc8+stable@fe2dd74d4d-20240414T1418Z.packages
9b638dca0ddc976797969a6422fc5bef2de8ec0bef9effbc794c391a00aada1f 
tails-arm64-6.2_raspi@dc0264f870+sta...@fe2dd74d4d-20240414t1215z.apt-sources
7029f74e0e0e2751054ed3b88dfb675516a0b676f47bc2dc5644aab729be191f 
tails-arm64-6.2_raspi@dc0264f870+stable@fe2dd74d4d-20240414T1215Z.build-manifest
360cde7f2bf7097fc85a127e4a84d61bc680875ec5144c2cef4b14374fad2638 
tails-arm64-6.2_raspi@dc0264f870+stable@fe2dd74d4d-20240414T1215Z.buildlog
c1bb35e768cc2961b75dbe539ea28c854fb1dee37b588c2114277c27395392f1 
tails-arm64-6.2_raspi@dc0264f870+sta...@fe2dd74d4d-20240414t1215z.img
d9967d1c353d4c0018cf899c8c19393886e2ae3c78938fbf73b069775a7d20cc 
tails-arm64-6.2_raspi@dc0264f870+sta...@fe2dd74d4d-20240414t1215z.iso
21f1a4fd4f098fccaef141c25dc67b18a185c38d42d8dfc14beeaa746b89f221 
tails-arm64-6.2_raspi@dc0264f870+stable@fe2dd74d4d-20240414T1215Z.packages



All the best!

n9iu7pk

PGP 7426 4598 B5AD 4D12 1699 C710 [ D602 E331 4D12 FFCB ]
https://keys.openpgp.org/search?q=D602E3314D12FFCB

On 13.04.24 13:55, noisyc...@tutanota.com wrote:

Hi n9iu7pk,

It looks like fixing uBlock is quite trivial, actually, so I did it myself. 
When an upstream patch becomes available I will revert my changes and apply 
that instead. The wip/* branches can now build the images.

I also uploaded the 6.2/* branches. These have exactly the same content as the 
corresponding wip/* branches, the difference being that the arm64/asahi/raspi 
patches are applied directly on top of stable instead of being buried below the 
newer commits, so they're easily identifiable. As stable gets updated I will 
keep rebasing them onto it (and merging the changes to wip/*) until the 6.2 
release, at which point I will freeze them.

Best,

NC

___
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.

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[NoisyCoil via Tails-dev]

Because the issue already has an assignee and I didn't want to be unpolite! :-) 
If groente is reading us and needs it, the patch is in attachment.
>From 8928015f4189fc2bb307343619b5d22bfaf7b28d Mon Sep 17 00:00:00 2001
From: NoisyCoil 
Date: Fri, 12 Apr 2024 20:03:27 +0200
Subject: [PATCH] Refresh uBlock-disable-autoUpdate.diff

---
 .../usr/share/tails/uBlock-disable-autoUpdate.diff  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config/chroot_local-includes/usr/share/tails/uBlock-disable-autoUpdate.diff b/config/chroot_local-includes/usr/share/tails/uBlock-disable-autoUpdate.diff
index 35d1da8229..be244ee7ed 100644
--- a/config/chroot_local-includes/usr/share/tails/uBlock-disable-autoUpdate.diff
+++ b/config/chroot_local-includes/usr/share/tails/uBlock-disable-autoUpdate.diff
@@ -1,6 +1,6 @@
 --- /usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/ublo...@raymondhill.net/js/background.js	2023-09-27 10:13:51.634749105 +0200
 +++ /usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/ublo...@raymondhill.net/js/background.js	2023-08-19 01:01:05.0 +0200
-@@ -100,7 +100,7 @@
+@@ -99,7 +99,7 @@
  const userSettingsDefault = {
  advancedUserEnabled: false,
  alwaysDetachLogger: true,
-- 
2.39.2

___
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.

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[anonym]

On 13/04/2024 13.55, NoisyCoil via Tails-dev wrote:

It looks like fixing uBlock is quite trivial, actually, so I did it
myself. When an upstream patch becomes available I will revert my
changes and apply that instead.

Why not submit your changes in a merge request to upstream? :)
___
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.

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[NoisyCoil via Tails-dev]

Hi n9iu7pk,

It looks like fixing uBlock is quite trivial, actually, so I did it myself. 
When an upstream patch becomes available I will revert my changes and apply 
that instead. The wip/* branches can now build the images.

I also uploaded the 6.2/* branches. These have exactly the same content as the 
corresponding wip/* branches, the difference being that the arm64/asahi/raspi 
patches are applied directly on top of stable instead of being buried below the 
newer commits, so they're easily identifiable. As stable gets updated I will 
keep rebasing them onto it (and merging the changes to wip/*) until the 6.2 
release, at which point I will freeze them.

Best,

NC
___
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.

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[NoisyCoil via Tails-dev]

Hi n9iu7pk,

I can confirm that everything's still alright with DNS redirection. I can 
successfully get the build to the point where it installs the debian packages 
on 6.1/raspi. The error you see is typical of when you're trying to install the 
packages from the original Tails repo. Since I disabled Tail's APT key 
verification, you'll only be able to install packages from the Debian archive 
(or, on the 6.1/raspi branch, from Raspberry's own repo, of which I added the 
key), and if you're not correctly hijacking the DNS and actually connecting to 
the Tails repo the build will fail with that error, it sees the repo is signed 
by Tails and rejects it. Since you said you previously built on the 6.1/raspi 
branch, I assume you are now correctly redirecting 
tagged.snapshots.deb.tails.boum.org as well, like I wrote before. Then I'm not 
sure what your issue could be. Perhaps you could try deleting the apt cache 
like you did the last time you had similar issues?


Asides from this, unfortunately the 6.1 branches will never build again due to 
https://gitlab.tails.boum.org/tails/tails/-/issues/20327. Debian sid's package 
webext-ublock-origin-firefox got updated to v1.57 some time after April 6th and 
the 10-tbb local hook (config/chroot_local-hooks/10-tbb) does not apply one 
patch cleanly anymore. As a result, the 99-zzz_check-for-dot-orig-files local 
hook makes the build fail with the error

```
Checking for .orig files
E: Some patches are fuzzy and leave .orig files around:
/usr/sbin/start-stop-daemon.orig
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/ublo...@raymondhill.net/js/background.js.orig
E: config/chroot_local-hooks/99-zzz_check-for-dot-orig-files failed (exit 
non-zero). You should check for errors.
```

Since the arm64 builds don't use snapshots, there's no way for me to prevent 
this kind of things. Unfortunately, if packages in Debian get upgraded, old 
builds may well fail. Since the 6.1/* branches are essentially frozen in time, 
I will not patch them. What I can and will do is keep an eye on the 
aforementioned issue and update the wip/* branches so that the fix gets picked 
up ASAP (I already have 6.2/* branches locally, but they will fail to build too 
until the ublock thing is fixed upstream).

BTW a package upgrade, I believe, is also the reason why you didn't obtain the 
same sha256sums when you  built 6.1/raspi. Again due to the lack of arm64 
snapshots, builds are reproducible only if packages are not subject to upgrades 
between an earlier and a later build, unfortunately. I'd bet if you'd compared 
your *.packages file with mine you'd have found differences.


If going ahead you have suggestions on how to improve the patchset feel free to 
tell me! If you find it useful you may even send me MRs on Gitlab, otherwise 
write here or send me a direct email.


En passing, do you happen to know how much space the amd64 Debian snapshots in 
use by Tails take up?


Best,

NC
___
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.

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[n9iu7pk]

Hi noisycoil,

yust FYI;

* on Apr., 08. I started a new 6.1/raspi build based on the latest pull: 
Got different sha256sum's than listed for your MEGA images. I assume 
that's what you ment with "Talking of reproducibility".


* currently I'm not able to build 6.1/raspi fails (reproduceable) with 
"E: Release signed by unknown key (key id 2453AA9CE4123A9A)" - might be 
missleading / overlaying a HTTP 404 caused by my DNS hijack


* I'll stop the builds for a while and will take some time to understand 
the build and your changes/commits better.


All the best!
n9iu7pk

PGP 7426 4598 B5AD 4D12 1699 C710 [ D602 E331 4D12 FFCB ]
https://keys.openpgp.org/search?q=D602E3314D12FFCB

On 03.04.24 02:24, noisyc...@tutanota.com wrote:

Hi n9iu7pk,

Thank you! Happy to hear you were able to build the other images as well.


Talking of reproducibility, I just added two fixup commits to the various branches to make the 
images more reproducible (in the sense of reproducible builds). The first one adds timestamps to 
the contents of /EFI/debian/efi.img (efi.img is a FAT image that contains the grub binary and its 
config file; these are responsible for UEFI boot on ISO hybrid images). The second one fixes (or 
rather removes) the BCJ filter used when building the squashfs with xz compression. It turns out 
that the filter which I had selected ("arm") is specific to 32-bit arm, cannot be used 
for 64-bit arm64 (I had never actually used xz compression!), and that the "arm64" BCJ 
filter is not available yet neither to mksquashfs nor to the kernel decompression routines (it is 
in xz-utils though, AFAICS). Fun fact: adding kernel support for the arm64 filter seems to be part 
of a recent patchset whose merge is now frozen due to the compromise of xz-utils (see 
https://lkml.org/lkml/2024/3/20/1010).


Thanks to the second commit one can now build tagged arm64 images using the 
following nginx configuration for DNS hijacking + URL redirection:


server {
     server_name time-based.snapshots.deb.tails.boum.org;

     rewrite ^/(debian|debian-security)/[0-9]+(/?.*) http://deb.debian.org/$1$2;
     rewrite ^/torproject/[0-9]+(/?.*) 
http://deb.torproject.org/torproject.org$1;
     rewrite ^/[0-9.]+(/?.*) http://deb.debian.org$1;

     location ~ 
^/(debian|debian-security|tails|torproject)/project/trace/(debian|debian-security|tails|torproject)
 {
proxy_pass http://204.13.164.63:80;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Protocol $scheme;
proxy_set_header X-Forwarded-Host $http_host;
     }

     location ~ ^/tails {
proxy_pass http://204.13.164.63:80;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Protocol $scheme;
proxy_set_header X-Forwarded-Host $http_host;
     }

     listen *:80;
}

server {
     server_name tagged.snapshots.deb.tails.boum.org;

     rewrite ^/[0-9a-z.-]+/(debian|debian-security)/(.*) 
http://deb.debian.org/$1/$2;
     rewrite ^/[0-9a-z.-]+/torproject/(.*) 
http://deb.torproject.org/torproject.org/$1;

     listen *:80;
}


Note the addition of tagged.snapshots.deb.tails.boum.org, which you must 
redirect to your webserver too (e.g. via /etc/hosts) to be able to build tagged 
images. Also, as I've already told you in a private email, I am now also 
redirecting to Tor's debian repository, which does support arm64.


Non-tagged images have snapshot timestamps in their apt sources, which spoils 
reproducibility (debian-security's snapshot timestamp, in particular, gets 
updated every day AFAICS). Thanks also to the timestamping of efi.img's 
contents, tagged arm64 images should on the other hand be reproducible during 
the time frame in which the packages downloaded from the Debian archive don't 
change: if you're lucky enough to build two arm64 images with the same package 
versions, then those images should be identical byte-for-byte. Of course, this 
is not actual reproducibility (which would need actual snapshots for the arm64 
component of the Debian archive so that the images are forever reproducible), 
but still, it's better than nothing.

I created three new branches, 6.1/arm64, 6.1/asahi and 6.1/raspi, which contain the same 
source code as their current wip/* analogue, but with the commits squashed and a tag 
(6.1-arm64, 6.1-asahi and 6.1-raspi) applied at the end of them. I do not plan to modify 
the content of those branches, which you may thus consider as arm64 6.1 
"releases" of my developer preview. The binary images built on the 6.1-* tags 
are in the usual MEGA folder. If you happen to build images on those tags in the near 
future, and the contents of the *.packages files are the same (which is essential to 
reproducibility), please let me know if you obtain the same 

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[NoisyCoil via Tails-dev]

Hi n9iu7pk,

Thank you! Happy to hear you were able to build the other images as well.


Talking of reproducibility, I just added two fixup commits to the various 
branches to make the images more reproducible (in the sense of reproducible 
builds). The first one adds timestamps to the contents of /EFI/debian/efi.img 
(efi.img is a FAT image that contains the grub binary and its config file; 
these are responsible for UEFI boot on ISO hybrid images). The second one fixes 
(or rather removes) the BCJ filter used when building the squashfs with xz 
compression. It turns out that the filter which I had selected ("arm") is 
specific to 32-bit arm, cannot be used for 64-bit arm64 (I had never actually 
used xz compression!), and that the "arm64" BCJ filter is not available yet 
neither to mksquashfs nor to the kernel decompression routines (it is in 
xz-utils though, AFAICS). Fun fact: adding kernel support for the arm64 filter 
seems to be part of a recent patchset whose merge is now frozen due to the 
compromise of xz-utils (see https://lkml.org/lkml/2024/3/20/1010).


Thanks to the second commit one can now build tagged arm64 images using the 
following nginx configuration for DNS hijacking + URL redirection:


server {
    server_name time-based.snapshots.deb.tails.boum.org;

    rewrite ^/(debian|debian-security)/[0-9]+(/?.*) http://deb.debian.org/$1$2;
    rewrite ^/torproject/[0-9]+(/?.*) 
http://deb.torproject.org/torproject.org$1;
    rewrite ^/[0-9.]+(/?.*) http://deb.debian.org$1;

    location ~ 
^/(debian|debian-security|tails|torproject)/project/trace/(debian|debian-security|tails|torproject)
 {
proxy_pass http://204.13.164.63:80;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Protocol $scheme;
proxy_set_header X-Forwarded-Host $http_host;
    }

    location ~ ^/tails {
proxy_pass http://204.13.164.63:80;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Protocol $scheme;
proxy_set_header X-Forwarded-Host $http_host;
    }

    listen *:80;
}

server {
    server_name tagged.snapshots.deb.tails.boum.org;

    rewrite ^/[0-9a-z.-]+/(debian|debian-security)/(.*) 
http://deb.debian.org/$1/$2;
    rewrite ^/[0-9a-z.-]+/torproject/(.*) 
http://deb.torproject.org/torproject.org/$1;

    listen *:80;
}


Note the addition of tagged.snapshots.deb.tails.boum.org, which you must 
redirect to your webserver too (e.g. via /etc/hosts) to be able to build tagged 
images. Also, as I've already told you in a private email, I am now also 
redirecting to Tor's debian repository, which does support arm64.


Non-tagged images have snapshot timestamps in their apt sources, which spoils 
reproducibility (debian-security's snapshot timestamp, in particular, gets 
updated every day AFAICS). Thanks also to the timestamping of efi.img's 
contents, tagged arm64 images should on the other hand be reproducible during 
the time frame in which the packages downloaded from the Debian archive don't 
change: if you're lucky enough to build two arm64 images with the same package 
versions, then those images should be identical byte-for-byte. Of course, this 
is not actual reproducibility (which would need actual snapshots for the arm64 
component of the Debian archive so that the images are forever reproducible), 
but still, it's better than nothing.

I created three new branches, 6.1/arm64, 6.1/asahi and 6.1/raspi, which contain 
the same source code as their current wip/* analogue, but with the commits 
squashed and a tag (6.1-arm64, 6.1-asahi and 6.1-raspi) applied at the end of 
them. I do not plan to modify the content of those branches, which you may thus 
consider as arm64 6.1 "releases" of my developer preview. The binary images 
built on the 6.1-* tags are in the usual MEGA folder. If you happen to build 
images on those tags in the near future, and the contents of the *.packages 
files are the same (which is essential to reproducibility), please let me know 
if you obtain the same sha256sums!


The tagged arm64 and asahi images don't pass one more test scenario, "APT 
sources are configured correctly", because of a failure in the very last step, 
where it is checked that the deb.tails.boum.org distribution in its 
apt.sources.d list file ("6.1", in our case) matches the build's git tag 
("6.1-arm64" or "6.1-asahi" or "6.1-raspi"). In theory I could make it so that 
the contents of the apt sources file match the git tag (e.g. by actually 
defining a new release version), but I believe this would make things works 
since deb.tails.boum.org does not provide "6.1-arm64" or "6.1-asahi" or 
"6.1-raspi" distributions, so apt would probably crash on update because of a 
non-existing repo! In practice I'm ok with this 

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[NoisyCoil via Tails-dev]

I forgot to say that you must also build your own Tor Browser for arm64, since 
the one which you'll find in the images is built by myself as well. These are 
the 3 Tor Browser for arm64 repos I'm aware of:

- Heikki Lindholm's: https://notabug.org/holin/tor-browser-build (he's been 
building arm64 releases for years now)
- my fork of Heikki Lindholm's repository: 
https://gitlab.com/NoisyCoil/tor-browser-build (very similar to the above 
except for minor technical differences; this is the one which I use for the 
13.0.x series in the Tails images)
- another one by me: https://gitlab.torproject.org/NoisyCoil/tor-browser-build 
(rewritten from scratch, only builds 13.5 alphas and nightlies, so this is not 
in use in Tails at the moment. There is an ongoing attempt to merge this 
upstream to provide official arm64 builds, see here: 
https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_requests/920)

Best,

NC
___
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.

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[NoisyCoil via Tails-dev]

Hi there.

If I were to speak as if I didn't build the images, I would tell you that you 
should NOT consider the prebuilt images as secure. Those are developer 
previews, not (yet) reproducible, uploaded by a random person on the internet. 
Even if that person is me, it would make no sense to trust me. What you can do 
to trust the images is building them yourself from source after reviewing the 
latter. Building the generic arm64 and Raspberry images is fairly easy 
(although it will take some time and you will need to hack your own DNS 
resolution to redirect from the Tails debian repository to the Debian archive, 
in order to obtain the arm64 packages), not quite so for the asahi images, 
because those use custom-built kernel and mesa drivers which are not available 
upstream. This means you must

1. build the kernel and mesa drivers
2. create your own debian repository (the image building process uses my own 
debian repository), upload them there and modify the Tails source code to use 
your own repository (the last part being the easiest one)
3. most importantly, the toolchain (compilers and the likes) for building the 
kernel and mesa drivers is NOT available in the Debian archive because both the 
asahi kernel and mesa drivers use versions of rust and the likes which are not 
available for bookworm, so you must also build the toolchain first. This means 
building roughly half of the debian packages hosted at 
https://gitlab.com/debian-asahi-nc (the other half is for debian testing) and 
then use those to compile the kernel and mesa drivers.

To be clear, the source code for building the arm64 Tails images is 100% 
publicly available. It is hosted at:

- https://gitlab.tails.boum.org/noisycoil/tails (wip/arm64, wip/asahi and 
wip/raspi branches: the actual arm64 Tails source code)
- https://gitlab.tails.boum.org/ 
noisycoil/gdm (a patched version 
of GNOME's GDM which is needed to make the automated test suite work on arm64 
and is installed in all recent images)
- https://deb.tails.boum.org/ (contains the debian source packages for various 
binary packages which have been modified for Tails itself and I rebuild 
verbatim for arm64. This is from Tails itself)
- https://gitlab.com/debian-asahi-nc (asahi kernel, mesa drivers and toolchain 
to build them)


But to set up the build infrastructure (DNS redirection, custom Tails packages, 
and Asahi packages if you need those) you'll need to work a bit. If you are 
interested you can write to me either here on the mailing list or in private.

At some point I think I will document the build process step-by-step, which I 
somewhat did on the mailing list, but in a non-systematic way.

Best,

NC
___
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.

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[jan kowalski]

How secure is usage of this image?
I went through instructions and was able to run Tails.
___
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.

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[NoisyCoil via Tails-dev]

Ah, alright, I was made aware of the retagging by reading on xmpp, where it was 
also mentioned that there had been a last-minute commit, so I thought the two 
things were one-off and related. It's the first time I follow a release almost 
live, the next time I'll know I must wait! No problem by the way.

31 mar 2024, 13:40 da ano...@riseup.net:

> On 29/03/2024 20.53, NoisyCoil via Tails-dev wrote:
>
>> en passing, to whoever caused the 6.1 retagging fuzz, I lost a full day
>> of testing work because of that, I hate you. Kidding <3
>>
>
> Actually this happens every single release, where there is a ~1 hour window 
> where you can fetch this to-be-overwritten tag. We know this isn't ideal, and 
> have been lazy about fixing this for years, but I just filed an issue 
> describing a pretty simple fix that I think we can put in use for Tails 6.2: 
> https://gitlab.tails.boum.org/tails/tails/-/issues/20314
>
> Sorry for the inconvenience! <3
> ___
> 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.

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[anonym]

On 29/03/2024 20.53, NoisyCoil via Tails-dev wrote:

en passing, to whoever caused the 6.1 retagging fuzz, I lost a full day
of testing work because of that, I hate you. Kidding <3


Actually this happens every single release, where there is a ~1 hour 
window where you can fetch this to-be-overwritten tag. We know this 
isn't ideal, and have been lazy about fixing this for years, but I just 
filed an issue describing a pretty simple fix that I think we can put in 
use for Tails 6.2: https://gitlab.tails.boum.org/tails/tails/-/issues/20314


Sorry for the inconvenience! <3
___
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.

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[n9iu7pk]

Hi NoisyCoil,

first of all: Impressive development the last weeks, thanks. I'm 
courious to see Tails runs on M1 & rp5. Lot of work to follow your work :D


> I'm not sure I understand what you were saying about base_branch, all 
I did is I rebased the arm64 patchset onto the stable branch, and more 
specifically over the 6.1 tag (en passing, to whoever caused the 6.1 
retagging fuzz, I lost a full day of testing work because of that, I 
hate you.
Solved / clarified: If you "switch" the git repo (i.e. from tails to 
yours) you should rebuild also the build vm. Meanwhile I can reproduce 
all builds (raspi, ashai and arm64) on a rp5 8GB.



Best regards!
n9iu7pk

PGP 7426 4598 B5AD 4D12 1699 C710 [ D602 E331 4D12 FFCB ]
https://keys.openpgp.org/search?q=D602E3314D12FFCB
___
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.

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[NoisyCoil via Tails-dev]

Hi n9iu7pk,

I had no issues rebuilding the Tails packages for arm64 from the source 
packages in the Tails debian repository, at least for the very few packages 
that are currently there. If I had modified the sources I think I would have 
remembered (and I would have published the modified sources), so I don't think 
I did. If you need help with a specific package just ask away.

Yes, I don't think hosting arm64 snapshots would be much different from x86_64. 
Versions would already coincide, as Debian usually builds the same versions for 
all archs at a given time.

I'm not sure I understand what you were saying about base_branch, all I did is 
I rebased the arm64 patchset onto the stable branch, and more specifically over 
the 6.1 tag (en passing, to whoever caused the 6.1 retagging fuzz, I lost a 
full day of testing work because of that, I hate you. Kidding <3). Those have 
stable as their base_branch. Previously the arm64 patches were applied to "a" 
devel branch (not even "the" devel branch), namely feature/bookworm, which is 
not there anymore having long been merged to stable.

Best,

NC
___
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.

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[NoisyCoil via Tails-dev]

Dear all,

I rebased the arm64 patches onto v6.1, marking the first build of the Tails for 
arm64 developer preview that's aligned with a stable release (you can find the 
images in the usual MEGA shared folder). In addition to the rebase, there are a 
number of new additions to the patchset, the most important being that I 
implemented the changes needed to run the automated test suite on the arm64 
proper (wip/arm64 branch) and asahi (wip/asahi branch) builds. So I'm happy to 
announce that the arm64 and asahi builds pass each and every single test 
scenario, except (of course) for those which depend on Tails infrastructure. 
Unfortunately, the Raspberry kernels are not virtualizable in the usual way 
(for starters, they lack every virtio driver), so I could not get the test 
suite to run on those.

More details and a description of the other changes in what follows.


*** Automated test suite ***

In order to run the automated test suite on the arm64 images, I had to overcome 
quite a few obstacles.

- First, I had to make the ISO images bootable via UEFI, which I hadn't done 
yet. For the record, I don't think ISO images are of much use in the arm64 
world.

- Second, it turns out that systems which boot via UEFI (like virtualized arm64 
systems) do not support internal snapshots, so I had to come up with an 
implementation of external snapshots for the Tails test suite. External 
snapshots can be activated via the undocumented `--external-snapshots` option 
to `run_test_suite`, and they completely replace internal snapshots when 
activated. Be warned that new step definitions that make creative use of 
snapshots may well break my implementation of external snapshots, as this is 
only guaranteed to work with the step definitions which are currently defined.

- Third, there is an annoying bug in GDM that makes arm64 VMs logout whenever 
`udevadm settle` or the likes is called. I had already noted this behavior in a 
previous email, but hadn't identified the cause yet (again, the behavior is 
specific to arm64 VMs only, although the bug itself exists for every arch and 
all hardware). Since the logouts heavily interfere with the tests' flow, I had 
to install a patched version of GDM in the images. The patch was fortunately 
already available in GDM v45, so I just had to backport it to v43. The source 
code for the patched GDM is at https://gitlab.tails.boum.org/noisycoil/gdm, and 
you can find the debian source and binary packages in the usual MEGA shared 
folder.

- Fourth, there is another annoying bug in arm64 qemu that makes it so plymouth 
doesn't work on arm64 VMs. Again this conflicts with the tests' flow. 
Fortunately, adding a couple of kernel parameters at boot time (within the 
testing logic itself, i.e. along with "autotest_never_use_this_option" etc.) 
fixes this.

- Fifth, arm64 VMs apparently cannot be booted via SATA CDROM drives, but only 
via SCSI CDROM drives, so on the one hand I had to define a domain for SCSI 
CDROM drives and use that for arm64, and on the other hand I had to include the 
virtio_scsi kernel module in the image's initramfs.

- Sixth, a number of checks, especially those related to syslinux and to 
installing Tails upgrades, do not apply to arm64. I had to disable those for 
arm64. Also, Tails tests only use UEFI boot, never MBR.

- Seventh, I found a bug and a soon-to-become bug in the test suite which 
directly impacted the arm64 tests (more precisely the wip/asahi tests). I have 
filed related bug reports and fixes have already been worked out by segfault. 
They will be probably released in v6.2 (one of them was already merged into 
stable), but in the meantime I backported them to the v6.1 arm64 build 
branches. These are https://gitlab.tails.boum.org/tails/tails/-/issues/20277 
and the now closed https://gitlab.tails.boum.org/tails/tails/-/issues/20276.

- Finally, I had to rebuild Tails' patched version of virt-viewer for arm64 and 
install it in my testing machines, which I did, and, again, you can find the 
source and binary debian packages in the usual MEGA shared folder.


You will find further details and references about these issues in the commit 
messages themselves. The Tails arm64 tests can be run by passing the `--arm64` 
option to `run_test_suite`, which makes the test suite use the correct default 
machine (features/domains/default-arm64.xml) and CDROM domains, implicitly 
enables `--external-snapshots`, disables the syslinux and Tails upgrade checks, 
enables UEFI unconditionally, passes the correct boot parameters, etc. These 
are technical changes which are essential to make the test suite run in the 
first place.

Beware that an 8GB RPi5 is already not quite powerful enough to run the tests 
cleanly (because of slow I/O, I would guess). The tests will indeed run 
(provided you set the GIC version to 2 in features/domains/default-arm64.xml) 
and most of them will pass, but for each run you can expect ~ 5-10% scenarios 
to randomly fail for no 

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[n9iu7pk]

Hi NoisyCoil,

anyhow I'm not finished with building, next step would be an apple 
silicon arm64e image as soon as I've got hardware. Also an rpi5 image 
build with on an arm platform. Would take some time/days, don't expect 
fast results.


How did you build the Tails packages for arm? I once fetched the sources 
from the apt repos and tried to re-compile/-build them on an arm 
platform (pain point have been all the dependencies as arm deb's). That 
was partially successful, but not for all packages.


Another point would be Tails snapshots from debian's apt repos (as 
currently that's mapped by the DNS hijack to latest always). I assume, 
that would be possible also for arm packages, on could follow the x86_64 
versions of packages of a given Tails snapshot to also create an arm 
snapshot - arm and x86 versions should not differ?



- 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.
I know that from experiments years ago with arm vm's runing with qemu on 
intel platforms. I was curious whether that would work for Tails 
somehow: It does! VERY slow but not that slow, that it is impossible. 
And YES, it's better to use an arm64 platform with >= 8GM RAM (rpi, 
rock, apple silicon and may others).



- 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 
` works.
Digged deeper into, might be caused by hybrid IPv4/IPv6 environment, 
debian-security had been resolved to IPv6 addresses that failed to be 
accessed as http resource.



- 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.
Somehow confused: base_branch defines, which branch will be cloned/used 
insde of the build VM while rake build. In case of "stable" even NOT the 
wip/raspi branch will be used to build, so how could a raspi image be 
build on "stable"?


Best regards!
n9iu7pk

PGP 7426 4598 B5AD 4D12 1699 C710 [ D602 E331 4D12 FFCB ]
https://keys.openpgp.org/search?q=D602E3314D12FFCB
___
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.

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[NoisyCoil via Tails-dev]

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 
` 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
___
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.

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[n9iu7pk]

Hi NoisyCoik,



The second and most exciting news is you can now cross-build Tails for
arm64 on an x86_64 machine! Keeping in mind that you still need to
hijack your DNS to download the arm64 packages, to build an arm64
version of Tails on x86_64:


After a couple of attempts & fails finally I could build a crossarm 
compiled raspberry pi 5 bootable (from USB) image - it was a big moment 
to see Tails running on rpi!


- Build platform: Intel i7 8 cores and > 32 GB RAM.

- followed your DNS hijack - with some changes see nginx.conf and 
docker-compose.yml below. In short: debian-security for example isn't 
available unsecure with http:// but only secure https:// and thus must 
be rewritten - redirect http to https would require a TLS server setup - 
too much efforts.


- forked from your/NoisyCoil's repository into 
https://gitlab.tails.boum.org/N9iu7pk/tails -> all changes to get a 
successfull build are pushed to this branch


- I used base_branch = 'wip/raspi'
   I'm not shure, whether that was the proper/intended choice. With 
'stable' or 'devel' the build ended up with building x86_64 instead of 
aarch64/arm64. Didn't investigated that any further.


- had some issues with certificates (i.e. raspi_chroot) and preparing 
apt sources (wip/raspi must be mapped to stable in 
auto/scripts/tails-custom-apt-sources)


- took day's for a first build (of course - running a full emulated arm 
VM on amd64 :D ). When choosing to keep the vm running afterwards, 
sometime the vm won't stop with rake vm:halt, had to kill qemu.


- without any build options the VM grabbed all 8 available cores and 50% 
of the available RAM


- Tor-Browser was running!

- the IMG was bootable, some issues
   * at boot time: failed to start systemd-sysctl.servide - apply 
kernel variables
   * when trying to modify stetting (language keyboard etc.) in the 
startup screen the system got "frozen"


I'd like to propose - as you already did - the two(or more)-image EFI 
idea (i.e. rpi and apple). Seems not to be an issue of ressources on 
users side (as todays usb-sticks < 64 GB becomes rare) but a problem of 
build ressources in terms of the timed snapshots from debian are doubled 
also for arm and nearly multiplied build timea are needed and for each 
platform an adjusted/modified kernel, dtb's & boot stack would be 
required -> which rather the task of projects like 
https://wiki.debian.org/DebianKernel/ARMMP.


Best regards
niuu7pk

PGP 7426 4598 B5AD 4D12 1699 C710 [ D602 E331 4D12 FFCB ]
https://keys.openpgp.org/search?q=D602E3314D12FFCB

events {}

http {
server {
server_name time-based.snapshots.deb.tails.boum.org;
listen *:80;
error_log /var/log/nginx/tails.log debug;
rewrite_log on;
rewrite ^\/(debian)\/pool(\/?.*) http://ftp.debian.org/$1/pool$2;
rewrite ^\/(debian-security)\/pool(\/?.*) 
https://deb.debian.org/$1/pool$2;
rewrite ^\/(debian)\/[0-9]+(\/?.*) http://ftp.debian.org/$1$2;
rewrite ^\/(debian-security)\/[0-9]+(\/?.*) https://deb.debian.org/$1$2;
rewrite ^\/[0-9.]+(\/?.*) https://deb.debian.org$1;

location ~ 
^/(debian|debian-security|tails)/project/trace/(debian|debian-security|tails) {
proxy_pass http://204.13.164.63:80;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Protocol $scheme;
proxy_set_header X-Forwarded-Host $http_host;
}

location ~ ^/(tails|torproject) {
proxy_pass http://204.13.164.63:80;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Protocol $scheme;
proxy_set_header X-Forwarded-Host $http_host;
}
}
}


docker-compose.yml
Description: application/yaml


OpenPGP_0xD602E3314D12FFCB.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
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.

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[NoisyCoil via Tails-dev]

Hi David,

Yes, I thought you'd already mentioned that. The quite long email I sent last 
week detailing some of the differences between the Apple Silicon and Raspberry 
Pi builds was also in response to you.

Something which I didn't address there is the possibility of cross-arch (!) 
images. Although I believe literally no distribution in human history has 
attempted something like this, I think that, paradoxically, building an 
arm64+x86_64 live image of Tails might be easier than building an image that 
works properly on two arm64 platforms with conflicting software requirements. 
If two platforms, one x86_64 and one arm64, boot via grub-efi at UEFI's 
removable path, then the latter is different for the two architectures 
(EFI/BOOT/BOOTAA64.EFI for arm64 and EFI/BOOT/BOOTX64.EFI for x86_64), so the 
two boot paths wouldn't conflict with each other and could coexist on the same 
medium. Each version of grub could then be configured to load the kernel and 
initramfs for its architecture, and live-boot (I think this is the right 
component) could be configured (or tweaked) to load the squashfs filesystem 
from an arch-specific path.

As for persistence, one could keep the behavior of arch-dependent and 
arch-independent files separate. For instance, one could share dotfiles, 
network configurations, greeter settings, etc. between architectures and create 
two separate "additional software" repositories on persistence storage, one for 
each arch.


A few downsides to this approach:

- It would double the size of the image, uselessly or almost so for most users
- It would require an almost-complete rewrite of the image-building process 
(live-build is unable to build this kind of arch-hybrid image)
- It still doesn't solve the issue of software incompatibilities between 
different arm64 hardware (see one of my previous emails for details on this), 
which of course has a higher priority and may not have a solution at all
- Sure as hell it would create a lot of issues as soon as, e.g., the system 
starts to store arch-dependent files as dotfiles (think of caches or binary 
config files!), and good luck to who has to deal with that


In the end it would probably be easier to make "Backup Persistent Storage" 
selective and allow the user to backup arch-independent files to a USB drive 
hosting a version of Tails for a different arch.

Best,

NC
___
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.

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[David A. Wheeler via Tails-dev]

> On Feb 18, 2024, at 9:03 AM, NoisyCoil via Tails-dev  
> wrote:
> TLDR; All Tails-specific apps now work on arm64 (with two minor "not-my-bug" 
> caveats). You can now cross-build Tails for arm64 on an x86_64 machine.

I think it'd be nice to have an ARM version of Tails, at least one that ran on 
Raspberry Pis & ARM Macs.
Bonus points if the same image could run on that *or* x86, as then people would 
be able to use
"the machine available to them". Then users could use a wide variety of 
machines.
(You might have to re-download any specialized apps installed on the
Persistent Storage for the "not currently loaded architecture.)

Whether or not doing that is *worth* the effort is obviously debatable, but I 
thought I'd raise it.

--- David A. Wheeler
___
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.

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[NoisyCoil via Tails-dev]

Dear all,

I have some exciting news.

TLDR; All Tails-specific apps now work on arm64 (with two minor "not-my-bug" 
caveats). You can now cross-build Tails for arm64 on an x86_64 machine.


First, as of my last commits, Tails Cloner now works on all my arm64 branches. 
This means that, with two exceptions (see ahead), all user-facing 
Tails-specific applications - namely Tails Cloner, Persistent Storage, Back Up 
Persistent Storage, Tails Documentation, WhisperBack -, plus the Tor Browser 
(the unofficial build) and OnionShare (factoring out the known bugs) now work 
on arm64. As for the other applications, I have not spent much time checking 
them one-by-one yet, so I can't promise anything, but in general they seem in 
good state.

The two exceptions to the above could be classified as "not my bug":

1. WhisperBack crashes at startup on Apple Silicon only. I believe this should 
be fixed upstream (I mean in the main Tails repos) so I've filed a bug 
(https://gitlab.tails.boum.org/tails/tails/-/issues/20200) and drafted a quick 
fix (https://gitlab.tails.boum.org/tails/tails/-/merge_requests/1410).

2. Creation of persistent storage misbehaves when running Tails in an arm64 VM. 
Hardware platforms (i.e. Apple Silicon and RPi) are not affected by this issue, 
nor are x86_64 VMs (I tested your Tails 6.0-rc1 build).
More precisely, when running in a VM, GDM restarts while creating persistent 
storage. The Tails greeter thus re-appears, and if you try to get past that the 
GNOME session doesn't go back to where it was. Persistent storage is still 
created correctly (the application runs to completion in the background!), but 
at that point there's not much you can do other than restart the VM. After 
restarting, everything works fine (including persistence).
I have determined that this is due to the "udevadm trigger" command internally 
run by tails-persistent-storage, and that this is not Tails specific: even on a 
vanilla Debian Bookworm arm64 installation, a VM will log out of the user 
session when "udevadm trigger" is called (but there's no Tails greeter workflow 
in vanilla Debian, so there you can just re-login). Since you already have 
https://gitlab.tails.boum.org/tails/tails/-/issues/20020, I will not address 
this issue at this moment.


The second and most exciting news is you can now cross-build Tails for arm64 on 
an x86_64 machine! Keeping in mind that you still need to hijack your DNS to 
download the arm64 packages, to build an arm64 version of Tails on x86_64:

- install the "binfmt-support", "qemu-user-static", "qemu-system-arm" and 
"qemu-efi-aarch64" Debian packages: sudo apt-get install -y binfmt-support 
qemu-user-static qemu-system-arm qemu-efi-aarch64
- include "crossarm64" in TAILS_BUILD_OPTIONS

Internally, cross-building works as follows. First binfmt-support and 
qemu-user-static automagically turn vmdb2 into a cross-arm64 image builder, so 
that an arm64 Vagrant box is built in place of an am64 one. Then the Vagrant 
box is run in emulation (via qemu proper instead of kvm) and does exactly the 
same job it would during a native build, only MUCH slower. And when I say "much 
slower" I mean it: on a last-generation 32-cores, 64GB x86_64 machine, my first 
build took 13 hours, the second one 6 hours, the third one 3-4 hours (depending 
on pre-existing caches), vs ~ 15 minutes for a native x86_64 build and ~ 1 hour 
on a 4-core 8GB Raspberry Pi 5 for a native arm64 build. So cross-builds should 
only be done when necessary (e.g. in production? ;-) ).

Note that I only attempted to cross-build on a single Ubuntu 23.10 machine, so 
the qemu configuration that's used for emulation may need some tweaks. For 
example, I'm not sure whether the "gic version='3'" feature, which is needed to 
emulate more than 8 cores (and up to 512, see 
https://www.qemu.org/docs/master/system/arm/virt.html) is supported on all 
x86_64 machines. If anybody attempts the cross build and it doesn't work, 
please write to me so we can get it fixed.


Best,

NC

___
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.

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[David A. Wheeler]

> On Feb 1, 2024, at 8:09 AM, anonym  wrote:
> 
> Hi,
> 
> First of all, very impressive work! Damn!

I agree.

Tails will have to decide how it wants to spend its limited resources.

In the long term, I think it'd be awesome to have a "unified" build that could
boot on x86 *and* a few common ARM systems (specifically Raspberry PIs,
Apple laptops, and maybe some ARM Chromebooks). That way, a user could
switch from one computer to another, with a different architecture,
and continue to work and use the data stored on the Persistent Storage.
Macs are more expensive, but not everyone can afford a second computer.
Raspberry PIs are widely available and inexpensive.
There would be a challenge for handling extra downloaded software,
but I think it's reasonable to say you have to re-download software for a 
different architecture.

Whether or not that's worth *doing* is a different task.

--- David A. Wheeler
___
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.

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[NoisyCoil via Tails-dev]

Hey there,

Thank you! I actually maintain my own private fork of Heikki Lindholm's arm64 
Tor Browser, but in the arm64 port of Tails I included Lindholm's own builds 
because those have been around for years now and are definitely more trusted 
than mine. They work perfectly, are well maintained and are as close as can be 
to the official x86_64 builds.

As for armhf, I'm not going to attempt building neither the Tor Browser nor 
Tails for that platform for a number of reasons, the first of which being I 
just don't own the required hardware. However, I'd expect that somebody else 
could take on if they are interested, as much of the work that goes into 
porting to arm64 could probably be translated to armhf (not all of it though!).

Also, thanks for the support! In the near future, when I find the time, I'm 
going to answer the other devs with some notes on how I made Tails boot on 
Apple Silicon and on the Raspberry 5. It was not rocket science, to be fair, 
but still worth documenting. I expect that - together with platform-specific 
quirks - to give the devs the bigger headaches if Tails will ever support arm64.

Best,

NC


Jan 28, 2024, 13:18 by n9iu...@posteo.net:

> Hi NoisyCoil,
>
>> ... This makes the Tor Browser
>> the single blocker for Tails on arm64 AFAICS (more on this later).
>>
> that helped me years ago to get Tor Browser running on a rpi -> 
> https://gitlab.torproject.org/legacy/trac/-/issues/12631
>
> Best Regards
> n9iu7pk
>
> Am 20.01.2024 16:43 schrieb NoisyCoil via Tails-dev:
>
>> *** For the casual reader: please do not use this version of Tails.
>> This is just a developer preview, it won't protect you like official
>> releases do ***
>>
>> Hey there,
>>
>> During the last few weeks I've been working on porting Tails to the
>> arm64 architecture, with the aim to ultimately being able to run Tails
>> on Apple hardware again. If anyone is interested in a developer
>> preview, you will find two USB images at
>> https://mega.nz/folder/BrJFGQyR#8rsN06I_pC_YV6spqATeBA. The code is
>> hosted at https://gitlab.tails.boum.org/noisycoil/tails in the
>> "wip/arm64" and "wip/asahi" branches. The former enables general arm64
>> support, while the latter contains additional, currently
>> non-upstreamable patches that make Tails run on Apple Silicon with
>> M1/M2 processors (no M3 support yet). In both cases, the builds are
>> native (you must build the arm64 version of Tails on arm64 hardware;
>> I've been building it on Apple Silicon (Asahi Debian) and on a
>> Raspberry Pi (Raspberry Pi OS) interchangeably).
>> The wip/asahi patches currently break amd64 builds due to a new entry
>> in the APT preferences file, but this can be fixed  (I didn't do so
>> yet because, as I said, the Asahi patches cannot be upstreamed anyway,
>> more on this later).
>>
>> Both the wip/arm64 and the wip/asahi images use GRUB for arm64 as a
>> boot loader. For the former, this is all there is at the moment,
>> meaning that the image can run in a VM, but may not run on hardware
>> that needs special firmware or arrangements to make it boot. As for
>> the latter, GRUB is all that's needed to boot on bare metal Apple
>> Silicon (from the Tails side, that is).
>> For those unfamiliar with the boot process on arm64 Apple hardware,
>> here's a quick recap. Out of the box, Apple Silicon does not support
>> booting from external media, nor of course booting Linux. It does,
>> however, support booting multiple macOSes from internal storage. The
>> smart folks at Asahi Linux (https://asahilinux.org/) came up with a
>> process to boot Linux both from internal and external storage (there
>> may be issues with booting from large external hard drives, but this
>> is not relevant to Tails). What they do is they install a fake macOS
>> on the hard drive, which after a couple of intermediate steps runs the
>> U-Boot boot loader (https://docs.u-boot.org/en/latest/), which is then
>> able to run GRUB both from internal and from external storage. This
>> mechanism is currently in use to run, among others, the official remix
>> of Fedora for Apple Silicon (https://asahilinux.org/fedora/), and -
>> except for the part where you actually have to install the boot loader
>> and for a second small exception, see below - is 100% transparent to
>> the user.
>>
>>
>> So how do you boot Tails on Apple Silicon?
>>
>> 1) Install U-Boot on your Apple Silicon Mac. This can be done using
>> the official Asahi installer (see https://asahilinux.org/):
>>
>> curl https://alx.sh | sh
>>
>> The correct option, which should only require around 3GB of storage
>> space on a separate partition, is "EFI environment only (m1n1 + U-Boot
>> + ESP)" and, crucially, does not require you to install a
>> fully-fledged Linux OS like Fedora. Once you do so, the U-Boot
>> partition will be set as the default boot partition. This can be
>> reverted at any time if you want to boot macOS by default instead (as
>> you probably do in the context of Tails). Also, the 

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[n9iu7pk]

Hi NoisyCoil,

 ... This makes the 
Tor Browser

the single blocker for Tails on arm64 AFAICS (more on this later).
that helped me years ago to get Tor Browser running on a rpi -> 
https://gitlab.torproject.org/legacy/trac/-/issues/12631


Best Regards
n9iu7pk

Am 20.01.2024 16:43 schrieb NoisyCoil via Tails-dev:

*** For the casual reader: please do not use this version of Tails.
This is just a developer preview, it won't protect you like official
releases do ***

Hey there,

During the last few weeks I've been working on porting Tails to the
arm64 architecture, with the aim to ultimately being able to run Tails
on Apple hardware again. If anyone is interested in a developer
preview, you will find two USB images at
https://mega.nz/folder/BrJFGQyR#8rsN06I_pC_YV6spqATeBA. The code is
hosted at https://gitlab.tails.boum.org/noisycoil/tails in the
"wip/arm64" and "wip/asahi" branches. The former enables general arm64
support, while the latter contains additional, currently
non-upstreamable patches that make Tails run on Apple Silicon with
M1/M2 processors (no M3 support yet). In both cases, the builds are
native (you must build the arm64 version of Tails on arm64 hardware;
I've been building it on Apple Silicon (Asahi Debian) and on a
Raspberry Pi (Raspberry Pi OS) interchangeably).
The wip/asahi patches currently break amd64 builds due to a new entry
in the APT preferences file, but this can be fixed  (I didn't do so
yet because, as I said, the Asahi patches cannot be upstreamed anyway,
more on this later).

Both the wip/arm64 and the wip/asahi images use GRUB for arm64 as a
boot loader. For the former, this is all there is at the moment,
meaning that the image can run in a VM, but may not run on hardware
that needs special firmware or arrangements to make it boot. As for
the latter, GRUB is all that's needed to boot on bare metal Apple
Silicon (from the Tails side, that is).
For those unfamiliar with the boot process on arm64 Apple hardware,
here's a quick recap. Out of the box, Apple Silicon does not support
booting from external media, nor of course booting Linux. It does,
however, support booting multiple macOSes from internal storage. The
smart folks at Asahi Linux (https://asahilinux.org/) came up with a
process to boot Linux both from internal and external storage (there
may be issues with booting from large external hard drives, but this
is not relevant to Tails). What they do is they install a fake macOS
on the hard drive, which after a couple of intermediate steps runs the
U-Boot boot loader (https://docs.u-boot.org/en/latest/), which is then
able to run GRUB both from internal and from external storage. This
mechanism is currently in use to run, among others, the official remix
of Fedora for Apple Silicon (https://asahilinux.org/fedora/), and -
except for the part where you actually have to install the boot loader
and for a second small exception, see below - is 100% transparent to
the user.


So how do you boot Tails on Apple Silicon?

1) Install U-Boot on your Apple Silicon Mac. This can be done using
the official Asahi installer (see https://asahilinux.org/):

curl https://alx.sh | sh

The correct option, which should only require around 3GB of storage
space on a separate partition, is "EFI environment only (m1n1 + U-Boot
+ ESP)" and, crucially, does not require you to install a
fully-fledged Linux OS like Fedora. Once you do so, the U-Boot
partition will be set as the default boot partition. This can be
reverted at any time if you want to boot macOS by default instead (as
you probably do in the context of Tails). Also, the U-Boot partition
can be deleted at any moment if you don't need it anymore

2) Burn the Asahi Tails image onto a USB drive as usual

3) Plug the USB drive into your Mac. If the U-Boot partition is the
default boot partition, just turn on your Mac. If it isn't, turn it on
by keeping the power button pressed until it says "Entering startup
options..." and then releasing it. At that point you can select the
U-Boot partition (similarly, if the U-Boot partition is the default
and you want to boot macOS, do the same but select the macOS
partition)

4) Hit ESC when U-Boot says you can do so in order to interrupt the
boot process and get dropped to a command line. Now you must tell
U-Boot you want to boot from an external USB (this is the second small
exception mentioned above): on the command line, execute

env set boot_efi_bootmgr
run bootcmd_usb0

This is the officially supported way to boot from an external USB
drive. Maybe at some point U-Boot will support doing so without the
user entering any command, but that's not possible at the moment
AFAIK.

5) That's it. You're in

If you happen to already have Asahi Linux installed on your arm64 Mac,
you don't need to follow Step 1 as U-Boot comes installed with the OS.
Just choose your Asahi Linux boot partition in Step 3.


As for the arm64 port itself, i.e. what's in the images. 

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[n9iu7pk]

Hi NoisyColi,

what a great work! That's the missing link! I tried that a couple of 
years ago, struggled on knowledge, missing platforms like M1/M2 and 
ARM's missing common boot process (might be less painful with EFI). And 
re-started last year as I learned from the Asahi project.


... This makes the 
Tor Browser

the single blocker for Tails on arm64 AFAICS (more on this later).
One of my first steps years ago was to build the Tor Browser from the 
official repo and run it on a RPI (wasn't arm64, I guess armhf), hope I 
can find my old stuff somewhere.


However, I hope that I can support you in some way. Thanks for sharing 
your work, keep on!


All the best!
n9iu7pk

Am 20.01.2024 16:43 schrieb NoisyCoil via Tails-dev:

*** For the casual reader: please do not use this version of Tails.
This is just a developer preview, it won't protect you like official
releases do ***

Hey there,

During the last few weeks I've been working on porting Tails to the
arm64 architecture, with the aim to ultimately being able to run Tails
on Apple hardware again. If anyone is interested in a developer
preview, you will find two USB images at
https://mega.nz/folder/BrJFGQyR#8rsN06I_pC_YV6spqATeBA. The code is
hosted at https://gitlab.tails.boum.org/noisycoil/tails in the
"wip/arm64" and "wip/asahi" branches. The former enables general arm64
support, while the latter contains additional, currently
non-upstreamable patches that make Tails run on Apple Silicon with
M1/M2 processors (no M3 support yet). In both cases, the builds are
native (you must build the arm64 version of Tails on arm64 hardware;
I've been building it on Apple Silicon (Asahi Debian) and on a
Raspberry Pi (Raspberry Pi OS) interchangeably).
The wip/asahi patches currently break amd64 builds due to a new entry
in the APT preferences file, but this can be fixed  (I didn't do so
yet because, as I said, the Asahi patches cannot be upstreamed anyway,
more on this later).

Both the wip/arm64 and the wip/asahi images use GRUB for arm64 as a
boot loader. For the former, this is all there is at the moment,
meaning that the image can run in a VM, but may not run on hardware
that needs special firmware or arrangements to make it boot. As for
the latter, GRUB is all that's needed to boot on bare metal Apple
Silicon (from the Tails side, that is).
For those unfamiliar with the boot process on arm64 Apple hardware,
here's a quick recap. Out of the box, Apple Silicon does not support
booting from external media, nor of course booting Linux. It does,
however, support booting multiple macOSes from internal storage. The
smart folks at Asahi Linux (https://asahilinux.org/) came up with a
process to boot Linux both from internal and external storage (there
may be issues with booting from large external hard drives, but this
is not relevant to Tails). What they do is they install a fake macOS
on the hard drive, which after a couple of intermediate steps runs the
U-Boot boot loader (https://docs.u-boot.org/en/latest/), which is then
able to run GRUB both from internal and from external storage. This
mechanism is currently in use to run, among others, the official remix
of Fedora for Apple Silicon (https://asahilinux.org/fedora/), and -
except for the part where you actually have to install the boot loader
and for a second small exception, see below - is 100% transparent to
the user.


So how do you boot Tails on Apple Silicon?

1) Install U-Boot on your Apple Silicon Mac. This can be done using
the official Asahi installer (see https://asahilinux.org/):

curl https://alx.sh | sh

The correct option, which should only require around 3GB of storage
space on a separate partition, is "EFI environment only (m1n1 + U-Boot
+ ESP)" and, crucially, does not require you to install a
fully-fledged Linux OS like Fedora. Once you do so, the U-Boot
partition will be set as the default boot partition. This can be
reverted at any time if you want to boot macOS by default instead (as
you probably do in the context of Tails). Also, the U-Boot partition
can be deleted at any moment if you don't need it anymore

2) Burn the Asahi Tails image onto a USB drive as usual

3) Plug the USB drive into your Mac. If the U-Boot partition is the
default boot partition, just turn on your Mac. If it isn't, turn it on
by keeping the power button pressed until it says "Entering startup
options..." and then releasing it. At that point you can select the
U-Boot partition (similarly, if the U-Boot partition is the default
and you want to boot macOS, do the same but select the macOS
partition)

4) Hit ESC when U-Boot says you can do so in order to interrupt the
boot process and get dropped to a command line. Now you must tell
U-Boot you want to boot from an external USB (this is the second small
exception mentioned above): on the command line, execute

env set boot_efi_bootmgr
run bootcmd_usb0

This is the officially supported way to boot from an external USB

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[intrigeri]

Hi,

NoisyCoil via Tails-dev (2024-01-19):
> The reason why I made this port is first, for fun.

I hope you had tons of fun! (I know I would have had :)

> But then also, to provide a PoC that Tails can already run on Apple Silicon 
> machines and that with some effort from various projects (Tails in providing 
> arm64 mirrors and packages, Tor in finally providing an official arm64 
> release of the Tor Browser, Debian in packaging the Asahi kernel and Mesa 
> libraries - until the Asahi changes get merged upstream), bringing Tails back 
> to Apple machines, and bringing it for the first time to arm64 hardware, is 
> just around the corner.

Thanks a lot! Such exploratory work is super useful. Not only in terms
of estimating how much it would take to get this ready for production
use, but also because it tells us what's the best we can currently
hope for, in terms of UX, if hypothetically all those blockers
were solved.

Cheers,
-- 
intrigeri
___
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.

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[boyska]

During the last few weeks I've been working on porting Tails to the arm64 
architecture, with the aim to ultimately being able to run Tails on Apple 
hardware again



wow, that seems to be really good hacking!

Thanks for doing that. While right now we have no upcoming plans for developing and maintaining 
Tails on arm64, this will help us in assessing how hard it could be to have one.


--
boyska
___
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.

Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)

[David A. Wheeler]

> On Jan 20, 2024, at 10:43 AM, NoisyCoil via Tails-dev  
> wrote:
> 
> *** For the casual reader: please do not use this version of Tails. This is 
> just a developer preview, it won't protect you like official releases do ***
> 
> Hey there,
> 
> During the last few weeks I've been working on porting Tails to the arm64 
> architecture, with the aim to ultimately being able to run Tails on Apple 
> hardware again.

This is very cool. It looks like you're also trying to get Tails to run on 
Raspberry PI, which would be awesome; that's also a widely-available platform. 
You might try getting to run well on Raspberry Pi first, as I suspect that is 
much easier.

Good luck.

--- David A. Wheeler
___
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.