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

Unsupported Platforms
84

Hey Sholenka, thanks a lot for being an alpha tester! :slight_smile:

Your discoveries are correct. Tor doesnā€™t have an official arm64 build, at least to my knowledge. Iā€™ve also been using Firefox for now. Regarding -drive "if=pflash,format=raw,file=./edk2-vars-work.fd,discard=on", youā€™re correct that itā€™s better to leave it out actually. I have updated the guide here with that already.

Regarding poor scaling and resolution, this is fixed when we use UTM as a frontend, because it has a SPICE implementation (basically a newer VNC protocol supported by QEMU).

The last few weeks have been very busy in work, but Iā€™ll hope to get the tutorial updated for UTM this coming week.

2 Likes
85

I tried the qemu commands in the guide, but that resulted in the error I described above. I got it working with the commands you posted in april where

  -netdev user,id=external,ipv6=off,net=10.0.2.0/24 \
  -netdev socket,id=internal,listen=:8010 \

is

-netdev socket,id=internal,connect=127.0.0.1:8010 \

for the workstation. So you might have to take a look if that has to be updated as well.

Maybe the Tor project will have some interest in porting the browser to arm64 now that Whonix has been ported? Could also be that it depends on libraries that have not been ported yet though. Seems to me that a significant part of the privacy/anonimity benefits of Whonix are only profited from when using the Tor browser.

Maybe something like this (https://github.com/ptitSeb/box86) could be used until then to run it? I donā€™t know much about methods of browser fingerprinting though so maybe this would make you stand out a lot.

1 Like
86

Tickets for Tor Browser arm64 already exists on Tor project issue tracker.

1 Like
87

It seems like development for it is dead for about a year now and does not seem to be a priority. I might add a comment maybe pointing out that adaption of the arm platform has been very rapid in the last year and that people would really benefit from Tor browser on arm now on Linux so maybe someone will become interested in woking on it (it runs fine under Rosetta translation on M1 Macs and under emulation on Windows on Arm, but native would always be better as well). I donā€™t know the dynamics of the open source community though as I am very new to it.

I might also open issues for other Whonix bundled apps that are also not present, like Onionshare.

Even though the Bitcoin wallet is not included, it seems to have been ported: Download - Bitcoin

And there is a Thunderbird build available without update support for now, and if there is sufficient interest they will work on it further: Thunderbird:AArch64 - MozillaWiki

Also, would having Whonix on aarch64 make it more suitable for running Android apps?

1 Like
88

Not present doesnā€™t necessarily indicate a Whonix or arm64 port specific issue. Unless available in current Whonix releases.

Onionshare is written in python. Hence, most likely architecture dependent. Please check if these applications work on Debian (buster) arm64 first. See also beginning from here: OnionShare Whonix integration development discussion - #27 by Patrick

Debian -- Details of package thunderbird in buster shows arm64. I would expect Thunderbird to be installable as per usual in Debian.

Also FYI:

1 Like
89

An interesting, new QEMU based virtualization option for Mac worth watching:

1 Like
91

Seems like an interesting option to offer if you want file sharing between the Workstation and the host. But for user friendliness and maybe security (donā€™t know how well Lima would be sandboxed on MacOS) UTM seems to be the best option in my opinion.

Also, hyper-v will gain support for Linux on arm soon (https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.13-ARM64-Hyper-V-Guest) so Whonix would be available to Windows on Arm soon as well.

I opened an issue on the Gitlab in the hopes of them taking new interest in porting the Tor browser to Arm: https://gitlab.torproject.org/tpo/core/tor/-/issues/40398. Until the Tor browser has been ported the privacy benefit is quite limited.

92

Someone of the Tor project commented on my issue that there is currently no timeline for Arm support. There is an unofficial port though. I guess official support will come eventually when Arm will reach a much larger user base, but not now in the short term.

I think it would still be worth it to switch from Virtualbox to UTM on the Mac, since UTM is much better. It will support Intel Macs and M1 Macs. For M1, people could use either Whonix natively without the Tor browser or they could emulate x86 Whonix for Tor browser support. I think the performance hit by emulation will be manageable with the performance of the M1 chip.

93

(No need for code tags. You can post regular links.)

Hyper-V is non-freedom software.

94

Reading the related TBB tickets the status is:

  • TBB arm64 for Windows and Mac are in the pipeline though no plans for Linux in the immediate future.
  • There are however unofficial builds from someone in their community which are being regularly built with new releases. This could be an acceptable stop gap IMHO. If you agree we can ask for signed tarballs in case it isnā€™t so at the moment.

Matthew Finkel @sysrqb Ā· 4 days ago

Developer

See also tor-browser-build#32355 (and Tor Browser Ports download | SourceForge.net, from a nice person in the community)

2 Likes
95

Would be a great idea to get the unofficial build on Whonix. I tried to build myself but did not succeed (I am a noob though). Major downside would probably fingerprinting though, as the userbase of TBB on Arm64 is would be extremely small. It sucks that they donā€™t work on a Linux port, because x86 TBB already runs good on M1 Macs and Windows on Arm, but Linux on Arm canā€™t run x86 apps.

I am hoping that most software on Linux will be ported to Arm when they get native Linux support on the M1 Macs: https://asahilinux.org/ . Since the Apple Silicon Macs have great hardware, performance and battery life and good price/quality ratio there might be a chance that it will become a popular Linux machine, and therefore make the Linux on Arm64 userbase much greater

3 Likes
96

Sounds good!

97

OK I sent a message on sourceforge asking for signed releases.

1 Like
98

Hi all, took some holidays recently, but back to this now. :slight_smile:

I did a thing:
https://github.com/Whonix/Whonix/pull/441

Please read the PR message. I need some guidance on where to put the UTM config files. For now, you can replace your local whonix-libvirt submodule with my fork here: GitHub - GavinPacini/whonix-libvirt: Whonix Libvirt XML Files for KVM - https://www.whonix.org/wiki/KVM in order to get the new utm build commands working.

Would appreciate someone testing it. It works very well for me, once merged and agreed on, Iā€™ll update the wiki.

3 Likes
99

I was wondering about that too. Good choices, looks great at first impression!

1 Like
100

Thanks Patrick! Iā€™ve fixed that MR comment you had. So, should I open a PR on whonix-libvirt for now also and then we can revisit a dedicated UTM package if needed in the future?

I also just want to note that once these changes are in master, it will reduce about 80% of the current wiki content related to Apple Silicon.

1 Like
101

I cannot really review that:

Similar to Whonix for KVM

Already merged. Pull requests are nice but git branches somewhere are also easy to merge on my side.

Awesome work!

Itā€™s all merged an included in Whonix git tag:

15.0.1.8.3-developers-only

Yes, if that makes sense, this could be done too.

Or could/should GitHub - Kicksecure/libvirt-dist: Libvirt XML Files for Derivative Linux Distributions KVM - https:/www.kicksecure.com/wiki/KVM / https://www.whonix.org/wiki/KVM be refactored anyhow? Or just renamed? It contains Linux libvirt XML KVM files for Whonix and Kicksecure, Whonix UTM (if we are going to use that term?) and bits for Linux KVM based Whonix-Host Operating System Live ISO, Whonix-Host Installer. Not sure how to split / organize all of that.

Optional of course, would you be interested to add a UTM file for Kicksecure too?

   utmfolder="${dist_binary_build_folder}/${VMNAME}.utm"
   sudo $SUDO_OPTS mkdir --parents "${utmfolder}/Images"
   mv "$binary_image_raw" "${utmfolder}/Images/${VMNAME}.raw"
   cp "$source_utm_file" "${utmfolder}/config.plist"

   tar -zcvSf "${dist_binary_build_folder}/${VMNAME}.utm.tar.gz" "$utmfolder"

One utmfolder per VM it is?

If that makes sense, and is possible, for better usability do you think you could make that a unified UTM release? Similar to unified Whonix VirtualBox and Whonix KVM releases. Historically there where separate downloads for gateway and workstation. Two folders. Two VMs to import for the user. Later this was unified into the same folder.

Unified images would probably be created using the prepare_release script instead of a Whonix build step.

Also modification of prepare_release to add UTM support would be good. Does prepare_release look understandable, possibly to modify? I was wondering if I should split it into separate scripts for simplification.

1 Like
102

Great work @GavinPacini. For the Workstation clipboard sharing should be disabled. Printer access should also be removed (IIUC this tag is for Apple print and not just the PrtScreen Key). Also system UUIDs should be stripped, leaving the emulator to generate whatever values it chooses.

2 Likes
103

Awesome, thanks for pulling those changes in!

For now, I think itā€™s fine. Maybe it could be renamed to whonix-qemu or something? As thatā€™s what all the files in there have in common. I do actually think a whole new package for two XML files (i.e. the UTM plist files) is overkill anyway.

Iā€™ve never used it, does it have the same concept of a Gateway and Workstation? I can take a look at it a bit later, but for now Iā€™ll prioritise getting the Mac UTM setup working well and updated on the relevant wikis. :slight_smile:

Yes, as far as I can tell there is no way to currently package them together. I know itā€™s not as simple as Virtualbox then, but for anyone using UTM thatā€™s what they would be used to. I donā€™t think itā€™s too bad.

It looks relatively fine. One question on it: is this run as part of the overall build script or something which is run manually when you want to package a new release?

Thanks for all the feedback as always!

Thank you! Hm, on my existing Intel Mac with Whonix clipboard sharing works. Maybe I enabled that afterwards? I know itā€™s a possible leak, so I will default it to disabled for our repo then (will issue a PR for that). Will also do the other cleanups you mentioned, thanks for the review!

2 Likes
104

Clipboard sharing: Whonix VirtualBox has it (usability). Whonix KVM doesnā€™t have it (security). We had a lengthy forum discussion about it, I swear, but I cannot find it anymore. Maintainer specific call.

Itā€™s separately wrong. (With same parameters as whonix_build.)

Cannot be run during whonix_build since it requires all VMs to be already build.
(Unless some assumption was added such as ā€œif workstation was build, consider weā€™re done and start prepare_releaseā€. Or if there was some whonix_build_multi script which existed before but just made the build process / script look more complex than it is.) Best design I could think off. Unless someone has a better idea how to structure things. :slight_smile:

Right. I ever considered having the UTM files in Whonix/Whonix (same as build script) but that also seemed non-ideal.

OK.

Worth combining both folders into one archive (KVM uses .xz to support sparse images) in prepare_release script? (Similar to Whonix KVM.) Then also the usual download table could be shared among VBox, KVM, UTM.

No. Actually simpler.