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

New project that lets one run x86 apps on Linux on arm64: GitHub - ptitSeb/box64: Box64 - Linux Userspace x86_64 Emulator with a twist, targeted at ARM64 Linux devices

1 Like

it is like UTM?

I have been using Whonix almost daily now on UTM and apart from some bugs it seems to be working good. OpenGL graphics acceleration support for Linux in UTM is currently in beta, so the experience should be even smoother soon.

Would it be possible to support UTM altogether to run Whonix on MacOS, both Apple Silicon and Intel? UTM is more secure than Virtualbox due to using qemu and the UTM app itself fully utilizes the MacOS sandbox. I have used the UTM build commands from @GavinPacini repeatedly and they work great on Apple Silicon.

I would be willing to write some documentation on how to install Whonix using the UTM build commands to make the documentation a bit simpler, and also some additional things (how to setup the Tor browser arm64 port, how to get the resolution right etc.) I could even build images myself and upload them for Apple Silicon. I don’t have an Intel Mac, but if someone else is willing to test if the build commands work on Intel then that would be great too.

@Hans No, it is just an emulator to run apps

2 Likes

It is a great idea! I can donate for this. We need a super easy manual step-by-step.

Please upload the image! Just bought UTM but having a hard time figuring out how to do this. I am also willing to contribute to this development!

Also, is there any reason why this requires 40gb of space? I want to make a portable Whonix VM.

1 Like

Please contribute to documentation and source code first:
(Written just now.)
Manual Builds vs Build Script Builds

Binary builds policy isn’t developed yet. Written just now:
Whonix ™ Binary Images Policy

1 Like

Now that Whonix 16 is out, what instructions can I follow to either, download pre-built images (preferred), or build the images for UTM?

1 Like

I am not a developer so I can’t contribute any code. I could write some documentation when I have more time. If that is not sufficient someone of the Binary Image Maintainers will have to build the images. I would certainly be happy to test those.

OK, after some digging it looks like 16.0.2.6-developers-only is the earliest tag I can use to build utm images with --target utm

After I do that, can I just rely on internal updates in the VM, or do I need to rebuild when a later stable version comes out?

Upgrade vs Image Re-Installation

I am trying to build the whonix-gateway-cli flavor with utm target. I get this error

clang: error: argument unused during compilation: '-fstack-clash-protection' [-Werror,-Wunused-command-line-argument]

I am using a freshly install arm64 debian bullseye VM in UTM and the command:

sudo ~/Whonix/whonix_build --flavor whonix-gateway-cli --target utm --repo true --arch arm64 --build

What am I doung wrong?

EDIT:
Forgot to mention I am using 16.0.2.6-developers-only tag

1 Like

Stupid question. Can I just use gcc to compile with an options somewhere? It seems that clang may have a bug in version 11 that causes this.

https://reviews.llvm.org/D96007

1 Like

Probably the hardened-malloc package failing to build? That’s “amd64” only anyhow. Nothing else requires clang. I’ll work on disabling hardened-malloc building for non-“amd64” builds.

Is this https://github.com/Whonix/Whonix/commit/6d5fad54c6eba1a9f8ad71d5be26b9a79b27d9d3 the fix for the hardened-malloc you mentioned?

If so, are there any security considerations in building the images from master or should I wait for a new tag?

I attempted a build from master and ran into this error.

I: Running cd /build/hardened-malloc-8/ && env PATH="/usr/sbin:/usr/bin:/sbin:/bin" HOME="/nonexistent" dpkg-buildpackage -us -uc -sa && env PATH="/usr/sbin:/usr/bin:/sbin:/bin" HOME="/nonexistent" dpkg-genchanges -S '-sa' > ../hardened-malloc_8-4_source.changes
dpkg-buildpackage: info: source package hardened-malloc
dpkg-buildpackage: info: source version 0:8-4
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Patrick Schleizer <adrelanos@whonix.org>
dpkg-buildpackage: info: host architecture arm64
 dpkg-source --before-build .
dpkg-source: info: using options from hardened-malloc-8/debian/source/options: --extend-diff-ignore=^\.travis\.yml$
 debian/rules clean
dh clean
 dpkg-source -b .
dpkg-source: info: using options from hardened-malloc-8/debian/source/options: --extend-diff-ignore=^\.travis\.yml$
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building hardened-malloc using existing ./hardened-malloc_8.orig.tar.xz
dpkg-source: info: building hardened-malloc in hardened-malloc_8-4.debian.tar.xz
dpkg-source: info: building hardened-malloc in hardened-malloc_8-4.dsc
 debian/rules binary
dh binary
 dpkg-genbuildinfo
dpkg-genbuildinfo: error: binary build with no binary artifacts found; .buildinfo is meaningless
dpkg-buildpackage: error: dpkg-genbuildinfo subprocess returned exit status 255

EDIT:
Sorry, bad form I forgot the important info

commit 5c85057be9c5e0244b2120be8efd28edfd0511f2 (grafted, HEAD → master, origin/master, origin/HEAD)

Actually should compile on arm64.

OK, I was able to successfully build 16.0.2.8-developers-only for the UTM target.

The VMs seem to run and function fine except for downloading the tor browser.
When I run update-torbrowser I get the following error:
ERROR: Failed to download: https://sourceforge.net/projects/tor-browser-ports/files/10.5.6/sha256sums-unsigned-build.txt.asc/download

Independent upstream. See:

The only source of Tor Browser arm64 builds as far as we’re aware.

That file was that file was only uploaded 4 hours ago so it might be functional by now.

Yep, it works now. I always get things at the wrong time.

1 Like

I got this the first time I tried to update, but figured the timeout would expire. It has reset multiple times now. Do I just need to leave it running for a day and then update it, or is it something else?

$ sudo apt update
[sudo] password for user:                     
Hit:1 tor+https://deb.debian.org/debian bullseye InRelease                     
Get:2 tor+https://deb.debian.org/debian bullseye-updates InRelease [39.4 kB]   
Get:3 tor+https://deb.debian.org/debian-security bullseye-security InRelease [44.1 kB]
Get:4 tor+https://deb.debian.org/debian bullseye-backports InRelease [40.9 kB] 
Get:5 tor+https://fasttrack.debian.net/debian bullseye-fasttrack InRelease [12.9 kB]
Get:6 tor+https://deb.whonix.org bullseye InRelease [39.6 kB]                  
Reading package lists... Done       
E: Release file for tor+https://deb.debian.org/debian/dists/bullseye-updates/InRelease is not valid yet (invalid for another 47min 32s). Updates for this repository will not be applied.
E: Release file for tor+https://deb.debian.org/debian-security/dists/bullseye-security/InRelease is not valid yet (invalid for another 4h 47min 29s). Updates for this repository will not be applied.
E: Release file for tor+https://fasttrack.debian.net/debian/dists/bullseye-fasttrack/InRelease is not valid yet (invalid for another 6h 35min 29s). Updates for this repository will not be applied.
E: Release file for tor+https://deb.debian.org/debian/dists/bullseye-backports/InRelease is not valid yet (invalid for another 47min 31s). Updates for this repository will not be applied.