Whonix on Mac M1 (ARM) - Development Discussion

[LoftyGoals]

This had fewer hiccups than I was expecting. Before I proceed to hammering VBoxManage into shape, does anyone see any problems with this approach?

These commands

• execute amd64 binaries
• using qemu-x86_64-static
• in an amd64 chroot
• in a mount of the Debian Bookworm amd64 Live ISO
• in an arm64 Debian bookworm VM (the same one I used to built he raw Whonix images)
• using VirtualBox 7.1.6
• on macOS Sequoia
• on an M1 Mac laptop

If this seems reasonable I will see if it can generate a working arm64 .vbox.

I’m kind of proud of this, particularly because it doesn’t require doing a Debian install… this is A-level cross-platform VM shenanigans. Nice idea, Patrick!

# Set variables for readability
AMD64_ROOT='/home/builder/amd64'
BINDIR_PATH='/home/builder/derivative-binary/17.3.6.2'
AMD64_WORK_PATH='/tmp/amd64_work'
RAW_FILENAME='Whonix-Gateway-CLI-17.3.6.2.arm64.raw'

# Set derived variables for readability.
RAW_PATH="${BINDIR_PATH}/${RAW_FILENAME}"
AMD64_ISO_PATH="${AMD64_ROOT}_iso"
AMD64_RO_PATH="${AMD64_ROOT}_ro"
AMD64_RW_PATH="${AMD64_ROOT}_rw"
AMD64_MERGED_PATH="${AMD64_ROOT}_merged"

# Download required items
sudo apt-get install curl qemu-user-static
curl -L -O https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.10.0-amd64-standard.iso

# Set up AMD64 file system and required files
mkdir "${AMD64_ISO_PATH}" "${AMD64_RO_PATH}" "${AMD64_RW_PATH}" "${AMD64_MERGED_PATH}" "${AMD64_WORK_PATH}"
sudo mount -o loop debian-live-12.10.0-amd64-standard.iso "${AMD64_ISO_PATH}"
sudo mount -o loop "${AMD64_ISO_PATH}/live/filesystem.squashfs" "${AMD64_RO_PATH}"
sudo mount --bind /dev "${AMD64_RO_PATH}/dev"
sudo mount --bind /sys "${AMD64_RO_PATH}/sys"
sudo mount --bind /proc "${AMD64_RO_PATH}/proc"
mkdir -p "${AMD64_RW_PATH}${BINDIR_PATH}"
mv "${RAW_PATH}" "${AMD64_RW_PATH}${RAW_PATH}"
sudo mkdir "${AMD64_RW_PATH}/etc"
sudo cp /etc/resolv.conf "${AMD64_RW_PATH}/etc"
sudo mkdir -p "${AMD64_RW_PATH}/usr/bin"
sudo cp $(which qemu-x86_64-static) "${AMD64_RW_PATH}/usr/bin"
sudo mount -t overlay overlay -olowerdir="${AMD64_RO_PATH}",upperdir="${AMD64_RW_PATH}",workdir="${AMD64_WORK_PATH}" "${AMD64_MERGED_PATH}"

# Run something
sudo /sbin/chroot "${AMD64_MERGED_PATH}" qemu-x86_64-static /usr/bin/apt-get install hello
sudo /sbin/chroot "${AMD64_MERGED_PATH}" qemu-x86_64-static /usr/bin/hello                
> Hello, world!
/usr/bin/dpkg --print-architecture
> arm64
sudo /sbin/chroot "${AMD64_MERGED_PATH}" qemu-x86_64-static /usr/bin/dpkg --print-architecture
> amd64

[LoftyGoals]

@Patrick

If running inside VirtualBox on Mac ARM64, could you please report a bug against systemd-detect-virt and/or fix it?

The good news is the problem exists in a vanilla Debian Bookworm VM in VirtualBox on an M1.

The bad news is Bookworm uses systemd 252.36-1~deb12u1 amd that is 3 major releases behind. It’s only 43 days out of date but they only accept bugs that are 1 or 2 major releases behind. So I can’t file a bug.

How should I proceed?

[Patrick]

Please try with Debian trixie.

[Patrick]

build-steps.d/1300_cowbuilder-setup is used to build chroots. Added some new code there just now.

   if [ "$dist_build_virtualbox" = "true" ]; then
      if [ "$dist_build_target_arch" = "arm64" ]; then
         true "${cyan}INFO: '--target virtualbox' and '--arch arm64', therefore also building a AMD64 chroot, because at time of writing VirtualBox is available only on ARM64 macOS but not for ARM64 Linux.${reset}"
         make_cross_build_platform_list_including_host_architecture+=" amd64 "
      fi
   fi

But…

• Installing VirtualBox inside that chroot using VirtualBox Installer for Linux (virtualbox-installer-cli (dist-installer-cli --virtualbox-only));
• using that chroot to run build-steps.d/4600_create-vbox-vm inside it;
• and combining this with SUDO_TO_VBOX_TEMP and/or HOMEVAR_VBOX_TEMP

remains todo.

[LoftyGoals]

@Patrick

1. • Installing VirtualBox inside that chroot using VirtualBox Installer for Linux (virtualbox-installer-cli (dist-installer-cli --virtualbox-only));
2. • using that chroot to run build-steps.d/4600_create-vbox-vm inside it;
3. • and combining this with SUDO_TO_VBOX_TEMP and/or HOMEVAR_VBOX_TEMP

@Patrick In the interest of not having to do it more than once and keeping it consistent with your vision, at what points in the code (file and section or line) do you imagine the three of these items happening?

Also, what is the digital-signatures-policy compliant way of installing VirtualBox Installer?

[LoftyGoals]

FYI, systemd-detect-virt false negative in Debian VM in VirtualBox on Sequoia · Issue #37204 · systemd/systemd · GitHub has been filed against systemd. If it isn’t resolved before I get everything else here running I’ll double back and bang on it.

[Patrick]

@Patrick

• Installing VirtualBox inside that chroot using VirtualBox Installer for Linux (virtualbox-installer-cli (dist-installer-cli --virtualbox-only));

This one done. And that was not easy at all.

@LoftyGoals

In the interest of not having to do it more than once

This might be incompatible with contributing.

Written just now;

First-Time Source Code Contributor Policy

@LoftyGoals

at what points in the code (file and section or line) do you imagine the three of these items happening?

Figuring that out would be part of the contribution. Some thing are easier to do than to explain.

Researching that, writing that down and clarifications would most likely take more time than implementing this.

[LoftyGoals]

Noted. I suspect it’s going to take me a little bit to get a reliably running system on M1. I will focus on getting that done and then I will look at some small bugs.

I’ve read the entire policy. I’m sure you don’t need my feedback but I appreciate you writing it up; it provides a good sense of what this project needs from (and can provide to) contributors.

FWIW, I do not see anything like a “good first issue” tag as mentioned in Final Notes. I can dig around in the tracker on my own, though.

[Patrick]

Created Good First Issues just now.