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

Unsupported Platforms
41

Actually not.

done

1 Like
42

Related build script enhancements:

Added:

  • raw image support
  • multiple architecture support

https://forums.whonix.org/t/long-wiki-edits-thread/3477/2009

https://github.com/Whonix/Whonix/commit/f5c0a78f30b68ee3c0bca29b72794f2152e7a520

Done?

Included in 15.0.1.7.6.

--flavor qcow2 / --flavor raw might be insufficient. --flavor qcow2 used to imply Linux libvirt (KVM).

  • I could rename --target to --format (image format).
  • Then --target would be virtualbox, libvirt, m1 (target platform).

Depending on what is required and what makes sense. Not sure that is already needed. Let me know what would be useful.

1 Like
43

build-steps.d/2376_build_arm64_fs is currently very slow for me. The update-grub step takes 40 minutes. Likely this needs to be improved:

mount --bind /dev "${mpoint_os}/dev"

Installing grub inside an image, a chroot is difficult. Most instructions mount the hostā€™s /dev inside the chroot. Not an immediate security risk but the image chroot has no business in the hostā€™s real /dev. Best avoided if possible.

/usr/sbin/grml-debootstrap uses instead:

mount -t devtmpfs udev ā€œ${MNTPOINT}ā€/dev

That might be a faster and more secure solution.
(Variable name change required.)
(Secure as in less likely to mess up something on the host or host disk grub config leaking into the VM.)
I havenā€™t tried yet if that would successfully build. And even if it did, I cannot test if it would boot.

1 Like
44

Great to see some progress on this! Hope there will be a more user friendly guide out in the near future.

I am not an advanced user and tried the guide, but I get stuck on how to build from master. I tried to run git checkout master but it gives me an error saying that master is not a path. So I ignored that part and built 15.0.1.7.3 stable but it failed building. I did add --arch arm64 --allow-untagged true at the end of the build command. Is there something really easy Iā€™m missing or should I just wait until this is developed more?

Update: I just used git checkout and then tried building 15.0.1.7.3-developers-only workstation. It fails here: https://anonfiles.com/jaYbDev8u4/Screenshot_2021-05-11_at_23.34.38_png

45

Hey Patrick, could you try with this patch please:
https://github.com/Whonix/Whonix/pull/440
It still builds and runs for me afterwards, but I cannot say if it really solves your issue because I never had your issue anyway. Although, agree itā€™s cleaner in general.

Thanks for trying this out! You need to either build from a newer tag (e.g. 15.0.1.7.8-developers-only ) or from master directly. Iā€™d recommend using 15.0.1.7.8-developers-only. Therefore, run git checkout --recurse-submodules 15.0.1.7.8-developers-only while inside the repo directory. Note, you might need to run git pull first.

Please try that and let me know how you get on.

P.S @Patrick, I noticed on the M1 section of the Mac Wiki pages, some of my longer commands are not showing in proper boxes. e.g. Section 3.3 ā€œRun the below command to run the gateway:ā€ is only showing a single line at a time. Iā€™m not the best with this Wiki markdown language, any ideas on how to fix that? I couldnā€™t spot any difference between my code boxes and others which are expanded. Thanks!

46

Thanks for the help. I tried it your way and get the following when trying to build the workstation: https://ibb.co/Ydf6pfr

When running git checkout --recurse-submodules 15.0.1.7.8-developers-only I get HEAD is now at 0745e88 instead of HEAD detached at 15.0.1.7.8-developers-only nothing to commit, working tree clean

47

Awesome! Will try.

A bug. My best guess, itā€™s caused by the expand box. I.e. the expand box incompatible with CodeSelect box. Letā€™s just drop the expand box, not important anyhow?

48

Can you please post more of the terminal output? The part you sent doesnā€™t actually show the error, it just shows that it was retried a few times (which the Whonix build script does). Ideally, run the command and redirect to a file. e.g.

sudo ./whonix_build --target raw --flavor whonix-workstation-xfce --build --arch arm64 > whonix_build_output.txt

Then upload whonix_build_output.txt somewhere for us to view.

Yes, that fixed it, thanks!

1 Like
49

Iā€™m making good progress on getting Whonix working with UTM, itā€™s an open-source QEMU-backed VM host for macOS (and iOS).

This would deliver a much better user experience for people wanting to get Whonix running on Apple Silicon. For many reasons:

  • It supports display scaling
  • Copy and paste works
  • Friendly UI as can be seen below (no need for QEMU commands in the terminal)

Screenshot 2021-05-15 at 13.44.33
Screenshot 2021-05-15 at 13.44.333360Ɨ1880 645 KB

It has a very simple XML based config too, so we could actually output this as part of our build script:

And package both the Workstation and Gateway into .utm files which work together. You can see an example of .utm files here: Debian 10.4 (Xfce) | UTM

What do you guys think of this? It would basically mean a similar experience as VirtualBox currently gives Mac Whonix users. It could also be backported for Intel Macs such that we recommend a FOSS version of running Whonix on all Macs.

1 Like
50

Tried it again, and this time it failed very early on. Here is a video with the commands and the text output:

https://justpaste.it/5zz55

https://www.youtube.com/watch?v=SJiT3WR_my8

Iā€™m quite busy now and the next few days so I wonā€™t be trying it again soon. It would be great if people could get it to work on UTM! If native ARM support still takes a long time, UTM supports running x86 operating systems on Apple Silicon with emulation (also ARM on Intel Macs with emulation btw)

EDIT: looking at the output I get the impression itā€™s just a mistake with the commands on my part. Will try it another time again

51

Thanks for that. Can you please try:

sudo ./whonix_build --target raw --flavor whonix-workstation-xfce --build --arch arm64 --allow-untagged true --allow-uncommitted true > whonix_build_output.txt
1 Like
52

UTM: Sounds great!

Whonix VirtualBox support for Mac for either Intel or M1 doesnā€™t have a dedicated maintainer. Therefore UTM might be better maintained.

How are .utm files required? Will the build process remain cross platform compatible or would parts of it be required to be executed on Mac?

Would Whonix UTM for Intel and M1 would require two different image downloads, one for each platform?

non-blocker: UTM says no hardware virtualization support, hence slower performance. Solvable issue? Any alternatives?

1 Like
53

Here is the output: https://justpaste.it/3tlip

54

This is the FAQ about the iOS App. Donā€™t know if there is also no hardware virtualization on the Mac. Apple has some info on virtualization support for the Mac:

https://developer.apple.com/documentation/virtualization

EDIT: This is the UTM page on the Mac App Store: ā€ŽUTM Virtual Machines on the MacĀ AppĀ Store

55

Was a worthwhile change. Also updated help-steps/chroot-raw to this syntax.

But it didnā€™t fix the issue. Itā€™s probably actually doing the very same thing as the old syntax.

Thatā€™s what help-steps/chroot-raw does not do. No mounting of sysfs. Therefore that is probably why previous calls to update-grub (by various Debian maintenance scripts by various packages) do not result in such major slow down.

grub-install needs sysfs. It fails without it. Tested.

But update-grub does not need sysfs. Tested.

Perhaps we can unmount sysfs after grub-install but before running update-grub? Tested. Build succeeded. Didnā€™t test boot.

56

https://github.com/Whonix/Whonix/commit/eb0f7e942ef4bd76e32de56b8596d87f536bde4a

Didnā€™t look into how to boot it with qemu. Therefore untested. Would it be a good use of development time to document how to start these images using qemu on the amd64 platform? Or maybe just for Kicksecure, not Whonix? (Because easier qemu / VM settings and boot process is the same.) If so, could you add qemu commands please?

If it doesnā€™t work, if it broke booting, please git revert. Or let me know. Iā€™ll git revert ASP.

All included in git tag 15.0.1.8.0-developers-only.

57

The .utm files are really just folders that contain two configuration files (XML) and the .raw image. So, they would definitely be buildable on another platform.

Regarding hardware virtualisation, that is indeed just lacking for the iOS builds. The macOS builds pass the -accel hvf flag to QEMU which enables hardware virtualisation using the macOS Hypervisor framework.

Thanks for this! Iā€™ll test it shortly and get back to you.

I agree, would be worth documenting how to run these images on amd64 (using QEMU to virtualise the arm64 images). I will test this myself on my main machine.

1 Like
58

Can you please run:

script -c "sudo ./whonix_build --target raw --flavor whonix-workstation-xfce --build --arch arm64 --allow-untagged true --allow-uncommitted true" ./whonix_build_output.txt

And then upload the file again?

I realised that because the build script spawns new shells it cannot redirect all output using normal unix redirection. This new file should contain all the output I need to help.

Although, I will say, in the file you uploaded it seems like it cannot find the right APT repository.

1 Like
59

Here you go: https://justpaste.it/635ps

60

Yeah, it seems to be this part:

Err:1 http://HTTPS///deb.torproject.org/torproject.org buster InRelease
  500  Connection failure: Connection refused [IP: 127.0.0.1 3142]
Reading package lists...
W: Failed to fetch http://HTTPS///deb.torproject.org/torproject.org/dists/buster/InRelease  500  Connection failure: Connection refused [IP: 127.0.0.1 3142]
W: Some index files failed to download. They have been ignored, or old ones used instead.

Iā€™ve never experienced that myself. It seems tor is not running properly on your Debian VM. Maybe someone else here has an idea? Also, I noticed youā€™re using parallels. In theory it should be fine but personally I built Whonix inside a QEMU backed Debian VM.