Whonix on Mac M1 (ARM) - Development Discussion

Development
1

Previous, mixed development discussion / user support discussion forum thread:
Whonix on Mac M1 (ARM) - User Support (still unsupported at time of writing)

If a developer is interested to contribute towards Whonix on Mac M1 (ARM) support, this forum thread can be used.

This forum thread is for developers only.

The latest best development news is still:

Which if merged would be super helpful for Whonix on Mac M1 (ARM) support. Even if not merged (soon), if there was a Whonix for Mac M1 (ARM) maintainer, I would accept carrying a mini fork of grml-debootstrap in derivative-maker help-steps folder.

Other than that, I am not aware of any contributor working on Whonix for Mac M1 (ARM) support. So no progress should be expected until that changes.

1 Like
2

//cc @GavinPacini

3

A post was merged into an existing topic: Whonix on Mac M1 (ARM) - User Support (still unsupported at time of writing)

4

https://www.reddit.com/r/Whonix/comments/zrdr4y/tor_browser_stuck_at_v1151_but_latest_is_1201/

5

The good news:

The bad news:

This is mostly only interesting for Kicksecure, not Qubes because Whonix for ARM64, which includes Mac M1, M2 is still unsupported at time of writing.

The situation might improve:

  • A) if thereā€™s either a maintainer for Whonix UTM or
  • B) if VirtualBox gets released for ARM64, because then I might be able to cross-build Whonix ARM64 VirtualBox builds.
6

TODO:

  • These .plist files need more work.
    • These settings should be compared with Whonix for KVM.
      • These are essential for Whonix as these define the VM settings such as these being linked together and other potentially security (or usability) related settings.

Step 1)

Look at Whonix KVM, something like:

  • virsh domxml-to-native qemu-argv ~/derivative-maker/packages/kicksecure/libvirt-dist/usr/share/libvirt-dist/xml/Whonix-Gateway.xml

  • virsh domxml-to-native qemu-argv ~/derivative-maker/packages/kicksecure/libvirt-dist/usr/share/libvirt-dist/xml/Whonix-Workstation.xml

  • virsh domxml-to-native qemu-argv ~/derivative-maker/packages/kicksecure/libvirt-dist/usr/share/libvirt-dist/xml/Kicksecure.xml

Step 2)

Add missing settings, if any, to the .plist files.

7

Hello there, itā€™s been a while! :slight_smile:

Today I pulled 17.1.1.5-developers-only and built two UTM packages for Intel_AMD64 that run great on my Intel Hackintosh via QEMU in UTM. I did have to change the version in packages/kicksecure/tb-updater/usr/share/tb-updater/tbb_hardcoded_version to get the build to work, seems Tor doesnā€™t keep old versions on their server unfortunately. But I anyway see this is fixed upstream and I could have also used --tb open.

I did this rather than trying with arm64 first because Iā€™m mainly working from my desktop these days, and after a busy period in life had some time to explore contributing to Whonix again.

I pushed some WIP changes to my fork of libvirt-dist: GitHub - GavinPacini/whonix-libvirt at feat/utm-intel-amd64 - Iā€™m successfully running the Intel_AMD64 versions of these configs. I havenā€™t tested the new arm64 configs just yet, but they should work as the diff is really just upgrading the config format for versions of UTM >=4. Iā€™m testing out cross-compiling arm64 builds from my Intel machine, but itā€™s taking a long time to build. Iā€™ll pull my changes onto my M1 Mac soon to test them there.

The folder layout changed slightly in recent versions of UTM too, so youā€™d also need to take these changes upstream: GitHub - GavinPacini/derivative-maker at feat/utm-intel-amd64

Other than that, it was very easy for me to get two UTM packages that work simply by running:

./derivative-maker --flavor whonix-workstation-xfce --target utm --arch amd64 --repo true --allow-uncommitted true --allow-untagged true

and

./derivative-maker --flavor whonix-gateway-xfce --target utm --arch amd64 --repo true --allow-uncommitted true --allow-untagged true

Happy to help get this over the edge properly and have redistributable UTM packages, I think itā€™s super close now.

ā€“
P.S: Great that the grml-debootstrap changes were taken upstream, the build scripts look way cleaner now!

1 Like
8

Welcome back!

UTM filenames now includes .arm64. Wonā€™t this require derivative-maker changes in help-steps/variables under source_utm_file?

If not too much work, could you please also provide (update the existing) plist files for Kicksecure? Thatā€™s useful to not have too many special cases for the build script and could be useful for testing / comparison too.

Git commits show youā€™re ahead by 1 commit but also behind, missing out on a few changes since. Could later lead to merge conflicts.

1 Like
9

Thanks Patrick!

Yes, I have also made those necessary changes, in a PR here: UTM support for Intel_AMD64 and upgrades to submodules by GavinPacini Ā· Pull Request #11 Ā· derivative-maker/derivative-maker Ā· GitHub

Of course, no problem. Iā€™ve updated my branch and opened a PR here: Add Intel_AMD64 UTM configs and upgrade arm64 configs by GavinPacini Ā· Pull Request #110 Ā· Kicksecure/libvirt-dist Ā· GitHub

Finally, I found some issues in tb-updater when running on arm64 and solved them here: Improved arm64 support by GavinPacini Ā· Pull Request #28 Ā· Kicksecure/tb-updater Ā· GitHub

1 Like
10

Replied on github. (tb-updater)

11

Merged. Thank you!

Having two different filesā€¦

  • usr/share/utm/Kicksecure.Intel_AMD64.plist
  • usr/share/utm/Kicksecure.arm64.plist

is unfortunate because it is just a 1 line difference.

Possible to leave out

	<string>x86_64</string>

vs

	<string>aarch64</string>

and let the virtualizer auto generate, handle that? Or not possible?

12

Thanks, will get back to this one on GitHub. :+1:

Good point, I should have realized the diff was super small, my bad. Iā€™ve gone ahead and updated my libvirt-dist and derivative-maker PRs to use a template file and sed so that we can just have one file for each flavor. I canā€™t find a way to get UTM to fill them in unfortunately.

1 Like
13

Merged. Thank you!

I am not a huge fan of sed string manipulation (helper-scriptsā€™s str_replace is a bit better but besides the point) but I guess in this case both solutions (duplicate files with almost same content) versus string are both non-ideal with string manipulation being the better option so thatā€™s an improvement.

1 Like
14

I hear you, me neither but in this case felt fine considering we shouldnā€™t need to change these files / strings often. If we do, Iā€™d say we call an XML parser which lets us target the specific element we want to change, or go back to two files.

1 Like
15

As an aside, I canā€™t build master right now. Seems to be that some packages depend on debhelper (>= 13.11.6). But, the most recent stable debhelper is 13.11.4. Do you use the backport or testing source? Or am I missing something else? Thanks!

I didnā€™t get this on the most recent tag 17.1.1.5-developers-only.

1 Like
16

Yes. I didnā€™t consider that yet. Yes, debhelper version from bookworm-backports needed.

Or maybe Iā€™ll make export make_use_cowbuilder=true the default.

17

Iā€™ve installed version 13.11.8~bpo12+1 of debhelper on my build machine, but still no luck. I also tried make_use_cowbuilder=true ./derivative-maker --flavor whonix-gateway-xfce --target utm --arch arm64 --repo true --allow-uncommitted true --allow-untagged true.

In both cases, the script fails here: derivative-maker/build-steps.d/2100_create-debian-packages at master Ā· derivative-maker/derivative-maker Ā· GitHub

With the underlying issue being:

Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 builddeps:/build/apparmor-profile-dist_8.9-1.dsc : Depends: debhelper (>= 13.11.6) but 13.11.4 is to be installed

I think I need to change the version of debhelper somewhere else but frankly not sure how.

1 Like
18

Just noticed cowbuilder is the default already anyhow.

Fixed here:

Should be fixed in the new tag.
17.1.1.7-developers-only and above.
No full build tested yet.

1 Like
19

Pretty confident the build should succeed. Please let me know if there are further issues.

1 Like
20

Yes, worked perfectly, thank you! I just tried:

./derivative-maker --flavor whonix-gateway-xfce --target utm --arch arm64 --repo true

Got a tar archive which once decompressed had the .utm package. A simple double click opened it and it booted perfectly in UTM.

What would we need to do next to get builds downloadable for users?

A cool distribution method could be the utm:// scheme. You can see an example of it on UTMā€™s gallery here: Debian 10.4 (Custom i3) | UTM

The ā€œOpen in UTMā€ button links to utm://downloadVM?url=https://github.com/utmapp/vm-downloads/releases/download/debian-10.4/debian-10.4-i3-arm64-utm.zip and we could have something very similar for Whonix Workstation and Gateway on the Whonix website so that itā€™s really a one (or two) click install.

1 Like