Whonix on Mac M1 (ARM) - Development Discussion

Development
21

Whonix on Mac M1 (ARM) - Development Discussion - #6 by Patrick seems important.

2 Likes
22

I’ve tried a few times to run the virsh domxml-to-native qemu-argv commands, but because I’m running Debian inside of qemu, it seems I cannot use kvm and so I get an error (error: invalid argument: could not get preferred machine for /usr/bin/qemu-system-x86_64 type=kvm). I’d need to change the XML file to use qemu alone, but at that point I’m modifying the XML which I’d rather avoid. Could someone with a host linux machine run these commands and send the outputs here?

I’ve got the full qemu args from UTM pulled out here (note, this has been pulled from my x86_64 system, but the relevant parts are the same across arm64 and x86_64/):

1 Like
23

Maybe CI (github actions based) would be useful to run these commands to show these options? Would also be a nice CI test. But github itself running virtualization. So that won’t help. Do you know some other free CI service which isn’t virtualization based, using real hardware?

1 Like
24

I don’t unfortunately, but I agree having this as part of CI that checks against some committed file for any surprising changes would be a really nice addition.

In the meantime, are you happy with the current UTM QEMU arguments? Or want me to change anything?

1 Like
25

Impossible to comment without basis for comparison.

26

I figured you would be able to run the virsh commands, but I remember @HulaHoop is responsible for Whonix for KVM. @HulaHoop could you please share the output of

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

so we can compare the QEMU args that UTM derives that I shared here: Whonix on Mac M1 (ARM) - Development Discussion - #22 by GavinPacini

Your help would be greatly appreciated!

2 Likes
27

Can you help please? @nurmagoz

2 Likes
28

Whonix-Gateway:

user@host:~/derivative-maker/packages/kicksecure/libvirt-dist/usr/share/libvirt-dist/xml$ sudo virsh domxml-to-native qemu-argv Whonix-Gateway.xml
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin USER=root HOME=/var/lib/libvirt/qemu/domain–1-Whonix-Gateway XDG_DATA_HOME=/var/lib/libvirt/qemu/domain–1-Whonix-Gateway/.local/share XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain–1-Whonix-Gateway/.cache XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain–1-Whonix-Gateway/.config /usr/bin/qemu-system-x86_64 -name guest=Whonix-Gateway,debug-threads=on -S -object ‘{“qom-type”:“secret”,“id”:“masterKey0”,“format”:“raw”,“file”:“/var/lib/libvirt/qemu/domain–1-Whonix-Gateway/master-key.aes”}’ -machine pc-i440fx-8.2,usb=off,vmport=off,dump-guest-core=off,mem-merge=off,memory-backend=pc.ram,hpet=off,acpi=on -accel kvm -cpu host,migratable=on,kvmclock=on,kvm-pv-unhalt=on,pmu=off -m size=524288k -object ‘{“qom-type”:“memory-backend-ram”,“id”:“pc.ram”,“size”:536870912}’ -overcommit mem-lock=off -smp 1,sockets=1,cores=1,threads=1 -uuid c567c4e6-f750-4ecb-ab90-321012c3d927 -device ‘{“driver”:“vmgenid”,“guid”:“99f50c12-3f81-4339-b390-c2fba5587b2c”,“id”:“vmgenid0”}’ -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain–1-Whonix-Gateway/monitor.sock,server=on,wait=off -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,clock=vm,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ‘{“driver”:“piix3-usb-uhci”,“id”:“usb”,“bus”:“pci.0”,“addr”:“0x1.0x2”}’ -device ‘{“driver”:“virtio-serial-pci”,“id”:“virtio-serial0”,“bus”:“pci.0”,“addr”:“0x5”}’ -blockdev ‘{“driver”:“file”,“filename”:“/var/lib/libvirt/images/Whonix-Gateway.qcow2”,“node-name”:“libvirt-1-storage”,“auto-read-only”:true,“discard”:“unmap”}’ -blockdev ‘{“node-name”:“libvirt-1-format”,“read-only”:false,“driver”:“qcow2”,“file”:“libvirt-1-storage”}’ -device ‘{“driver”:“virtio-blk-pci”,“bus”:“pci.0”,“addr”:“0x6”,“drive”:“libvirt-1-format”,“id”:“virtio-disk0”,“bootindex”:1}’ -netdev ‘{“type”:“tap”,“fd”:“17”,“vhost”:true,“vhostfd”:“28”,“id”:“hostnet0”}’ -device ‘{“driver”:“virtio-net-pci”,“netdev”:“hostnet0”,“id”:“net0”,“mac”:“52:54:00:78:69:11”,“bus”:“pci.0”,“addr”:“0x3”}’ -netdev ‘{“type”:“tap”,“fd”:“29”,“vhost”:true,“vhostfd”:“30”,“id”:“hostnet1”}’ -device ‘{“driver”:“virtio-net-pci”,“netdev”:“hostnet1”,“id”:“net1”,“mac”:“52:54:00:f5:5c:a2”,“bus”:“pci.0”,“addr”:“0x4”}’ -chardev pty,id=charserial0 -device ‘{“driver”:“isa-serial”,“chardev”:“charserial0”,“id”:“serial0”,“index”:0}’ -chardev spicevmc,id=charchannel0,name=vdagent -device ‘{“driver”:“virtserialport”,“bus”:“virtio-serial0.0”,“nr”:1,“chardev”:“charchannel0”,“id”:“channel0”,“name”:“com.redhat.spice.0”}’ -audiodev ‘{“id”:“audio1”,“driver”:“spice”}’ -spice port=5901,addr=127.0.0.1,disable-ticketing=on,disable-agent-file-xfer=on,seamless-migration=on -device ‘{“driver”:“virtio-vga”,“id”:“video0”,“max_outputs”:1,“bus”:“pci.0”,“addr”:“0x2”}’ -object ‘{“qom-type”:“rng-random”,“id”:“objrng0”,“filename”:“/dev/urandom”}’ -device ‘{“driver”:“virtio-rng-pci”,“rng”:“objrng0”,“id”:“rng0”,“bus”:“pci.0”,“addr”:“0x7”}’ -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=

Whonix-Workstation:

user@host:~/derivative-maker/packages/kicksecure/libvirt-dist/usr/share/libvirt-dist/xml$ sudo virsh domxml-to-native qemu-argv Whonix-Workstation.xml
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin USER=root HOME=/var/lib/libvirt/qemu/domain–1-Whonix-Workstation XDG_DATA_HOME=/var/lib/libvirt/qemu/domain–1-Whonix-Workstation/.local/share XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain–1-Whonix-Workstation/.cache XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain–1-Whonix-Workstation/.config /usr/bin/qemu-system-x86_64 -name guest=Whonix-Workstation,debug-threads=on -S -object ‘{“qom-type”:“secret”,“id”:“masterKey0”,“format”:“raw”,“file”:“/var/lib/libvirt/qemu/domain–1-Whonix-Workstation/master-key.aes”}’ -machine pc-i440fx-8.2,usb=off,vmport=off,dump-guest-core=off,mem-merge=off,memory-backend=pc.ram,hpet=off,acpi=on -accel kvm -cpu host,migratable=on,kvmclock=off,kvm-pv-unhalt=on,pmu=off -m size=1572864k -object ‘{“qom-type”:“memory-backend-ram”,“id”:“pc.ram”,“size”:1610612736}’ -overcommit mem-lock=off -smp 1,sockets=1,cores=1,threads=1 -uuid aebc953d-a3ef-40f4-a080-bbddd0bc9351 -device ‘{“driver”:“vmgenid”,“guid”:“fd6de7ed-c6d3-43c0-9325-0ba2d4394069”,“id”:“vmgenid0”}’ -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain–1-Whonix-Workstation/monitor.sock,server=on,wait=off -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -global kvm-pit.lost_tick_policy=delay -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ‘{“driver”:“piix3-usb-uhci”,“id”:“usb”,“bus”:“pci.0”,“addr”:“0x1.0x2”}’ -device ‘{“driver”:“virtio-serial-pci”,“id”:“virtio-serial0”,“bus”:“pci.0”,“addr”:“0x5”}’ -blockdev ‘{“driver”:“file”,“filename”:“/var/lib/libvirt/images/Whonix-Workstation.qcow2”,“node-name”:“libvirt-1-storage”,“auto-read-only”:true,“discard”:“unmap”}’ -blockdev ‘{“node-name”:“libvirt-1-format”,“read-only”:false,“driver”:“qcow2”,“file”:“libvirt-1-storage”}’ -device ‘{“driver”:“virtio-blk-pci”,“bus”:“pci.0”,“addr”:“0x6”,“drive”:“libvirt-1-format”,“id”:“virtio-disk0”,“bootindex”:1}’ -netdev ‘{“type”:“tap”,“fd”:“26”,“vhost”:true,“vhostfd”:“28”,“id”:“hostnet0”}’ -device ‘{“driver”:“virtio-net-pci”,“netdev”:“hostnet0”,“id”:“net0”,“mac”:“52:54:00:51:33:f5”,“bus”:“pci.0”,“addr”:“0x3”}’ -chardev pty,id=charserial0 -device ‘{“driver”:“isa-serial”,“chardev”:“charserial0”,“id”:“serial0”,“index”:0}’ -chardev spicevmc,id=charchannel0,name=vdagent -device ‘{“driver”:“virtserialport”,“bus”:“virtio-serial0.0”,“nr”:1,“chardev”:“charchannel0”,“id”:“channel0”,“name”:“com.redhat.spice.0”}’ -audiodev ‘{“id”:“audio1”,“driver”:“spice”}’ -spice port=5901,addr=127.0.0.1,disable-ticketing=on,disable-copy-paste=on,disable-agent-file-xfer=on,seamless-migration=on -device ‘{“driver”:“virtio-vga”,“id”:“video0”,“max_outputs”:1,“bus”:“pci.0”,“addr”:“0x2”}’ -device ‘{“driver”:“intel-hda”,“id”:“sound0”,“bus”:“pci.0”,“addr”:“0x4”}’ -device ‘{“driver”:“hda-output”,“id”:“sound0-codec0”,“bus”:“sound0.0”,“cad”:0,“audiodev”:“audio1”}’ -object ‘{“qom-type”:“rng-random”,“id”:“objrng0”,“filename”:“/dev/urandom”}’ -device ‘{“driver”:“virtio-rng-pci”,“rng”:“objrng0”,“id”:“rng0”,“bus”:“pci.0”,“addr”:“0x7”}’ -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on

Kicksecure:

user@host:~/derivative-maker/packages/kicksecure/libvirt-dist/usr/share/libvirt-dist/xml$ sudo virsh domxml-to-native qemu-argv Kicksecure.xml
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin USER=root HOME=/var/lib/libvirt/qemu/domain–1-Kicksecure XDG_DATA_HOME=/var/lib/libvirt/qemu/domain–1-Kicksecure/.local/share XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain–1-Kicksecure/.cache XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain–1-Kicksecure/.config /usr/bin/qemu-system-x86_64 -name guest=Kicksecure,debug-threads=on -S -object ‘{“qom-type”:“secret”,“id”:“masterKey0”,“format”:“raw”,“file”:“/var/lib/libvirt/qemu/domain–1-Kicksecure/master-key.aes”}’ -machine pc-i440fx-8.2,usb=off,vmport=off,dump-guest-core=off,mem-merge=off,memory-backend=pc.ram,hpet=off,acpi=on -accel kvm -cpu host,migratable=on,kvmclock=off,kvm-pv-unhalt=on,pmu=off -m size=1572864k -object ‘{“qom-type”:“memory-backend-ram”,“id”:“pc.ram”,“size”:1610612736}’ -overcommit mem-lock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 51458204-52f4-4400-a335-8c491c0d2552 -device ‘{“driver”:“vmgenid”,“guid”:“b0b49359-2f5e-46d5-aa38-0b0e55751e06”,“id”:“vmgenid0”}’ -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain–1-Kicksecure/monitor.sock,server=on,wait=off -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -global kvm-pit.lost_tick_policy=delay -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ‘{“driver”:“piix3-usb-uhci”,“id”:“usb”,“bus”:“pci.0”,“addr”:“0x1.0x2”}’ -device ‘{“driver”:“virtio-serial-pci”,“id”:“virtio-serial0”,“bus”:“pci.0”,“addr”:“0x5”}’ -blockdev ‘{“driver”:“file”,“filename”:“/var/lib/libvirt/images/Kicksecure.qcow2”,“node-name”:“libvirt-1-storage”,“auto-read-only”:true,“discard”:“unmap”}’ -blockdev ‘{“node-name”:“libvirt-1-format”,“read-only”:false,“driver”:“qcow2”,“file”:“libvirt-1-storage”}’ -device ‘{“driver”:“virtio-blk-pci”,“bus”:“pci.0”,“addr”:“0x6”,“drive”:“libvirt-1-format”,“id”:“virtio-disk0”,“bootindex”:1}’ -netdev ‘{“type”:“tap”,“fd”:“26”,“vhost”:true,“vhostfd”:“28”,“id”:“hostnet0”}’ -device ‘{“driver”:“virtio-net-pci”,“netdev”:“hostnet0”,“id”:“net0”,“mac”:“52:54:00:33:6a:10”,“bus”:“pci.0”,“addr”:“0x3”}’ -chardev pty,id=charserial0 -device ‘{“driver”:“isa-serial”,“chardev”:“charserial0”,“id”:“serial0”,“index”:0}’ -chardev spicevmc,id=charchannel0,name=vdagent -device ‘{“driver”:“virtserialport”,“bus”:“virtio-serial0.0”,“nr”:1,“chardev”:“charchannel0”,“id”:“channel0”,“name”:“com.redhat.spice.0”}’ -audiodev ‘{“id”:“audio1”,“driver”:“spice”}’ -spice port=5901,addr=127.0.0.1,disable-ticketing=on,disable-copy-paste=on,disable-agent-file-xfer=on,seamless-migration=on -device ‘{“driver”:“virtio-vga”,“id”:“video0”,“max_outputs”:1,“bus”:“pci.0”,“addr”:“0x2”}’ -device ‘{“driver”:“intel-hda”,“id”:“sound0”,“bus”:“pci.0”,“addr”:“0x4”}’ -device ‘{“driver”:“hda-output”,“id”:“sound0-codec0”,“bus”:“sound0.0”,“cad”:0,“audiodev”:“audio1”}’ -object ‘{“qom-type”:“rng-random”,“id”:“objrng0”,“filename”:“/dev/urandom”}’ -device ‘{“driver”:“virtio-rng-pci”,“rng”:“objrng0”,“id”:“rng0”,“bus”:“pci.0”,“addr”:“0x7”}’ -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on

2 Likes
29

Could you add this to Whonix /Dev/KVM wiki please?

1 Like
30

Done.

1 Like
31

Thanks @nurmagoz!

I’m not really a QEMU hardening expert, so I’ve asked ChatGPT to help in comparing the CLI args. I don’t think that it’s a hardening expert either, but I do think it’s a good start (1 is KVM, 2 is UTM):

Gateway:

Comparing the two QEMU configurations reveals several key differences in terms of how they are set up and intended to be used. Below is a breakdown of the main distinctions between the first and second configurations:

Machine Type and Version

  1. First Configuration: Uses the pc-i440fx-8.2 machine type, which is a specific version of the i440FX architecture.
  2. Second Configuration: Uses the q35 machine type, a newer chipset model that supports more modern hardware emulation and features.

Acceleration

  1. First Configuration: Specifies -accel kvm for acceleration, which uses the KVM hypervisor in Linux.
  2. Second Configuration: Uses -accel hvf indicating Hyper-V support, tailored for macOS (UTM uses this for near-native performance).

Graphics and Display

  1. First Configuration: Utilizes a virtio-vga device for video output.
  2. Second Configuration: Employs a virtio-gpu-gl-pci device with OpenGL support, indicating potentially better graphical performance and features like 3D acceleration.

Storage

  1. First Configuration: Uses a QCOW2 file format for the main disk (Whonix-Gateway.qcow2).
  2. Second Configuration: Operates with a raw disk image (Whonix-Gateway-Xfce.raw), which can offer faster disk access at the cost of some features like snapshots.

Network

  1. First Configuration: Configures two TAP devices for network connectivity, with explicit MAC addresses and vhost acceleration.
  2. Second Configuration: Includes one user-mode network with NAT (netdev user) and one socket-based network, potentially for inter-VM communication or specific network setups.

USB Devices

  1. First Configuration: Does not explicitly enable USB support.
  2. Second Configuration: Explicitly enables USB support and includes devices like a USB tablet, mouse, keyboard, and uses USB redirection for advanced features, likely enhancing user interaction with the VM.

Memory

  1. First Configuration: Allocated with 512 MB RAM.
  2. Second Configuration: Allocated with 2048 MB RAM, providing more memory for applications to run within the guest.

Additional Hardware and Features

  • First Configuration: Includes specific devices like isa-serial, rng-random, and security features through -sandbox options.
  • Second Configuration: Adds an Intel HDA audio device with duplex support, several USB redirection devices, and uses the SPICE protocol for enhanced remote display capabilities, including OpenGL rendering.

System Configuration and Boot Options

  • First Configuration: Focuses on a minimal boot with strict options and specific device addresses.
  • Second Configuration: Leverages UEFI boot (if=pflash) and includes more flexible and high-level features, likely to support a broader range of guest OS features or for a more user-friendly setup within a GUI environment like UTM.

Purpose and Environment Adaptation

  • First Configuration: Seems tailored for a specific, perhaps security-focused, VM setup in a Linux environment with KVM.
  • Second Configuration: Appears designed for use on macOS within the UTM application, offering a more graphical and user-friendly experience with support for advanced features like OpenGL and SPICE.

These configurations reflect different use cases and optimization choices, targeting different host environments (Linux with KVM vs. macOS with Hyper-V) and possibly different end-user requirements, such as performance, usability, or specific hardware emulation needs.

Workstation:

Comparing the two QEMU configuration commands reveals a range of differences in how each virtual machine (VM) is set up. These differences are rooted in the specific use cases, performance requirements, security considerations, and underlying hardware support. Below, I’ll highlight the key distinctions:

1. General Configuration and Machine Type

  • First Config: Uses pc-i440fx-8.2 machine type, which is a traditional and stable option, offering broad compatibility with a wide range of operating systems.
  • Second Config: Uses q35, a newer machine type that provides better performance and more advanced features than i440fx, including support for PCIe devices, making it a better choice for modern operating systems and hardware.

2. Acceleration

  • First Config: Specifies -accel kvm, indicating the use of KVM (Kernel-based Virtual Machine) for acceleration, which is typical for Linux hosts.
  • Second Config: Uses -accel hvf, which stands for Hardware Virtualization Framework, a macOS-specific virtualization framework that leverages the hardware capabilities of Apple’s processors to provide fast and efficient virtualization.

3. Graphics and Display

  • First Config: Relies on SPICE for display, with various SPICE-related options configured, and uses a virtio-vga device for video output.
  • Second Config: Also uses SPICE for display but specifies gl=on for OpenGL acceleration and configures a virtio-gpu-gl-pci device, emphasizing better graphical performance and possibly 3D acceleration.

4. Storage

  • First Config: Utilizes a QCOW2 file format for the VM’s disk (Whonix-Workstation.qcow2), which is a flexible and efficient format for QEMU VMs, supporting features like snapshots.
  • Second Config: Opts for a raw disk image (Whonix-Workstation-Xfce.raw), which generally offers better performance at the cost of storage efficiency and advanced features like snapshots.

5. USB and Peripheral Devices

  • First Config: Has minimal USB device configuration, focusing primarily on the VM’s core functionality.
  • Second Config: Includes comprehensive USB support with devices like usb-tablet, usb-mouse, usb-kbd, and multiple usb-redir devices for USB redirection, indicating a stronger focus on user interaction and peripheral integration.

6. Networking

  • First Config: Configures a single Virtio network device connected to a tap interface, suitable for bridged or NAT-based networking setups.
  • Second Config: Specifies a virtio-net-pci device with a socket-based netdev for networking, which might be tailored for a specific networking setup or integration with other VMs or services.

7. Miscellaneous

  • First Config: Includes various devices and options for compatibility and functionality, such as intel-hda for sound, RNG (Random Number Generator) devices for entropy, and specific ACPI settings for power management.
  • Second Config: Incorporates more advanced features like EFI boot (if=pflash), highlighting a more modern VM setup, potentially offering better compatibility with recent operating systems requiring EFI.

Summary

The first configuration is tailored for a Linux host environment, focusing on a balance between performance and compatibility, using traditional virtualization techniques and devices. The second configuration is designed for a macOS host, leveraging specific macOS virtualization frameworks and hardware features for potentially better performance and user experience, especially in terms of graphics and USB device support.

Based on this output, there doesn’t seem to be huge differences, it seems that the main differences are simply what’s required for Mac/UTM/Arm support. However, I will look into minimizing the USB devices and including some of the security features i.e. rng from host and sandbox settings (although I think the sandbox settings won’t add anything to an already sandboxed OS like macOS).

Let me know if you guys spot something else that should be focused on!

1 Like
32

Back to square one a bit later but…

Since it’s using full emulation, QEMU anyhow… Why do we need ARM64 builds? Why not just use the AMD64 builds on Mac M1?

33

It’s not really emulating on macOS, it uses hvf, which is a macOS specific framework / QEMU accelerator.

If we did run AMD64 builds on Apple Silicon, we would have to emulate which would lead to degraded performance. With the current setup, we have both AMD64 and ARM64 UTM builds working in the derivative-builder. I’m running them both, one on my hackintosh and one on my M1 laptop.

1 Like
34

That is actually interesting and important information for developers. Even advanced users might ask about this.

Where?

For VirtualBox, there is:

New wiki page? Dev/UTM?

(Gonna get back to the other topic soonish.)

35

The VM settings are of crucial importance. One would have to go through all of these options one by one, reading the man page and perhaps related materials.

Ideally UTM could use libvirt then UTM could share most of Whonix KVMs configuration more easily rather than using QEMU command line directly. That would simplify things, make different virtualizer support simpler, since these would be more similar.

This is very important, needs most attention to get right to avoid IP leaks.

From the UTM config files. Relevant options:

Whonix-Gateway

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

Whonix-Workstation

-device virtio-net-pci,netdev=internal
-netdev socket,id=internal,connect=127.0.0.1:8010

Doesn’t look crazy. Related documentation:
https://wiki.qemu.org/Documentation/Networking

But it has the same issue that KVM has. VM internal traffic is visible on the host for network sniffers such as wireshark, tshark.

This has lead in the past to a failure of configuring corridor on a Debian host with Whonix KVM.

references:

related:

So it would be much better if KVM / QEMU (UTM) would hide this from the host operating system. I.e. encapsulate the internal networking better. ChatGPT says this is possible using the hubport option but ChatGPT unfortunately sometimes talkes nonsense. Could you look into it please?

https://chat.openai.com/share/8d7165c4-722a-4e06-8cfd-8b525c552784

related:
USB Passthrough

rng-random would be important to add if that is possible somehow.

Not security related. Usability only. Low priority. Could QCOW2 be used too? (derivative-maker supports it. Just a question if UTM supports it too.)

Created Dev/UTM - Whonix just now.