Whonix on Mac M1 (ARM) - User Support (still unsupported at time of writing)

[Patrick]

The update-grub step…

@Patrick

  WARNING: Device /dev/loop7p1 not initialized in udev database even after waiting 10000000 microseconds.

taking a very long time and above warnings has been resolved with the following commit:

remove os-prober from non-qubes-vm-enhancements-cli

Included in:

15.0.1.8.6-developers-only

[0xdeadbeef]

Thanks for all the hard work that’s gone into this. I can confirm that I’ve got Whonix working on M1 locally after following these instructions, great work from all involved!

[Patrick]

ARM64 Tor Browser Maintainer

Info for the trust section in the TBB documentation: Heikki Lindholm https://sourceforge.net/u/holind Builds will soon feature a dev signed sha256sum hash file of all builds for verification. He’s also contributed in the past to gnunet, libmicrohttpd, jackaudio and Debian’s xorg package. public key from: https://h-lindholm.net/pubkey pub ed25519/6AF15D1E45FDCEC9 2021-06-06 [C] [expires: 2024-06-05] Key fingerprint = 24F1 41A3 B988 B6C3 50B9 3758 6AF1 5D1E 45FD CEC9 uid …

[Patrick]

ARM64 Tor Browser

I know that the Tor browser tries to mask itself as the same across all operating systems. Do you know / can you ask whether this build can hide that it runs on a different architecture? Otherwise it does not seem very useful to stay anonymous due to the extremely small user pool Edit by Patrick: related: https://forums.whonix.org/t/arm64-tor-browser-maintainer/11786

[Patrick]

ARM64 Tor Browser

Tor Browser Downloader by Whonix ™ has been improved to support downloading Tor Browser ARM64 from sourceforge.net by Heikki Lindholm. Related: ARM64 Tor Browser Maintainer The goal is to make Tor Browser Downloader by Whonix ™ work out of the box on arm64 without special command line options / environment variables required. I guess that already works but I cannot test (due to lack of hardware and or better said due to infeasibility of running unlimited architectures/virtualizers at the same …

[Sholenka]

I’m trying it now. Tor Browser Downloader does not seem to be installed or present in the Start Menu.

[Patrick]

It’s not automatic / pre-installed yet. Perhaps in the next build.

1. Need the updated tb-updater package.
2. Run update-torbrowser. (As per in link in previous post.)

For any issues, logs would be needed to diagnose.

[Sholenka]

Got the downloader installed. When I launch it I get an error that tor is not fully bootstrapped possibly due to having no internet connection.

When I boot up the Gateway VM for the first time I get an error that greater onion service is not running, but if I relaunch everything I can just browse and install packages like normal. Maybe this has something to do with it.

[Patrick]

These are general issues. Unrelated to tb-updater. These issues might be fixed in the testers repository if you enable that and upgrade all packages in gateway and workstation, the issues might be gone. Are they? If not, we have to debug because I thought these are resolved. These issues however will break tb-updater “as a side effect”.

Meanwhile to work around and isolate testing tb-updater, the --no-tor-con-check parameter which will Skip Tor bootstrap connectivity check. might be helpful.

update-torbrowser --no-tor-con-check

[Sholenka]

I upgraded all packages in both VM’s, the issues persist. I downloaded TBB with your workaround and installed tb-starter, but it seems that it downloaded the normal TBB. When I try to launch it I get “Tor browser requires a CPU with SSE2 support”

[Patrick]

I need the output of update-torbrowser.

If architecture auto detection fails, that can surely be fixed. Please report. Workaround if that was to happen:

ARCH=arm64 update-torbrowser

In that case please run in debug mode and share the output here.

bash -x update-torbrowser

In case of download / verification failures, please also run in debug mode.

ARCH=arm64 bash -x update-torbrowser

---

For onion-grater I also need from the gateway:
Daemon Log View for:

onion-grater

(If repetitive, I don’t need to see too much of the same.)

[Sholenka]

I was a bit confused by your block so here is the output for different commands:

Output " update-torbrowser": Output update-torbrowser - JustPaste.it

Ouput “update-torbrowser --no-tor-con-check”: Ouput update-torbrowser --no-tor-con-check - JustPaste.it

Output " ARCH=arm64 update-torbrowser --no-tor-con-check": Output "ARCH=arm64 update-torbrowser" - JustPaste.it (still can’t run TBB)

Output “bash -x update-torbrowser”: Output "bash -x update-torbrowser" - JustPaste.it

Daemon log view of gateway gives: – No entries –

[Patrick]

Version too old. You need tb-updater 3:19.9-1 (or above).

Did you enable the testers repository as per Whonix APT Repository?

And you always need --no-tor-con-check until the onion-grater issue is fixed.

Daemon log view of gateway gives: – No entries –

Did you run

sudo journalctl -b --no-pager -u onion-grater

?

[Sholenka]

That was it, I didn’t enable it. Tor Browser is installed and launches! Can’t wait for the UTM port so it will have the full user experience.

I might have made a typo earlier when trying to get the Daemon Log View, so maybe that’s why it didn’t work. Here is the output when I use sudo journalctl -b --no-pager -u onion-grater :

[Patrick]

onion-grater does not show any issues.

@Sholenka

When I launch it I get an error that tor is not fully bootstrapped possibly due to having no internet connection.

When I boot up the Gateway VM for the first time I get an error that greater onion service is not running, but if I relaunch everything I can just browse and install packages like normal. Maybe this has something to do with it.

Is this still happening after testers upgrades?

great onion service = onion-grater?

When you re-run systemcheck after a while does it pass all good?

[Sholenka]

I don’t get an error anymore when starting tb-updater from the GUI. Everything seems to be fine now, will make a post here if I encounter any issues

[Sholenka]

I have Whonix running with UTM with the build commands of @GavinPacini. I just used the UTM build commands, unpacked the tar files and opened the .utm files. Didn’t touch any other files. Copy and paste with the host works out of the box. A couple of issues I notice rightaway:

• Moving windows has terrible graphics issues. This sometimes is resolved by making the VM another fullscreen window. Videos also don’t play smoothly.

• When entering mission control and back out of it when the VM is another fullscreen window, two black bars occur above and under the desktop

• The Whonix desktop takes up more horizontal space than the “borders” of the VM for some reason. As a result, when I try to make a window fullscreen in the VM it goes beyond the right side of the VM screen.

[Sholenka]

I have the graphics issues less when using Whonix on non-UTM QEMU. Could it be due to UTM not having the patch for accelerated graphics like normal QEMU has after installing these packages linked in the Whonix wiki for M1? GitHub - knazarov/homebrew-qemu-virgl: A homebrew tap for qemu with support for 3d accelerated guests

[GavinPacini]

Firstly, I haven’t forgotten about some items on my side. I still want to

1. Update the wiki
2. Work on the release script so we can have automatic UTM builds
3. Test and integrate Tor ARM builds.

Busy with the day job right now. Hopefully calms down soon and I can contribute some more.

@Sholenka, I’ve noticed this too, sporadically. It could be caused by a few things:

1. Sometimes the rendering occurs on the efficiency cores of the M1. Option to only use performance cores when automatically determining core count · Issue #2557 · utmapp/UTM · GitHub
2. Something related to SPICE / the video device being used. Graphics artifacts on Apple Silicon host (high screen tearing and mouse disappearing) · Issue #2569 · utmapp/UTM · GitHub
3. Or the fact that 3D acceleration is missing because UTM is not using the patches available (although I think this is not going to really affect drawing normal windows). GitHub - knazarov/homebrew-qemu-virgl: A homebrew tap for qemu with support for 3d accelerated guests

Possibly even a mix of the above. Once I again have some more time, this is something else I want to tackle. Seeing as UTM already has those open GitHub issues, maybe someone else will solve it before me. But, I wanted to link them so you can follow the progress.

For your issue on Whonix taking up “more space” than the UTM window, if you run xrandr --output Virtual-1 --auto in the terminal once your UTM window is in an appropriate size, it should rescale correctly (sometimes you need to run this command a few times). It’s a known bug in XFCE: add support for xrandr hotplug_mode_update property / SPICE resize support (#142) · Issues · Xfce / xfce4-settings · GitLab

There are also some other workarounds proposed here: linux kvm - No Auto Resize with SPICE and virt-manager - Super User

I’ll probably incorporate something into the build and also make sure people know about these current limitations once I update the wiki. At least they are here in the forum for now.

[Sholenka]

Thanks. Hope that things will get sorted out. UTM makes the user experience quite a bit better. In case you want to add it to the wiki later, I found how to set up a shared directory between a VM and the host.

• Right click VM → Edit → Sharing → Enable Directory Sharing → Save

• Select the directory of the host on the main UTM screen

In the VM:

sudo apt install spice-vdagent spice-webdavd

sudo apt-get install davfs2

Make the directory in the VM to link with the one in the host and link them:

sudo mkdir /mnt/dav

sudo mount -t davfs -o noexec http://127.0.0.1:9843/ /mnt/dav

More on how to share a custom folder / directory on MacOS: Set up file sharing on Mac – Apple Support (UK)

edit: I’m only managing to get files from the host to VM this way, not from VM to host