Whonix-Host Operating System (OS) ISO

[onion_knight]

Great!

[Patrick]

Not sure reading manpages alone can explain the differences but it’s certainly a good start. Hard to find a justification / explanation why Debian has two tools for update-initramfs (a wrapper) vs mkinitramfs. Intution tells me that the wrapper isn’t entirely useless but the provided benefit is unclear. Looking at the source code. Found one interesting thing.

/usr/sbin/update-initramfs contains:

# Invoke bootloader
run_bootloader()
{
	# invoke policy conformant bootloader hooks
	if [ -d /etc/initramfs/post-update.d/ ]; then
		run-parts --arg=${version} --arg=${initramfs} \
			/etc/initramfs/post-update.d/
		return 0
	fi
}

/usr/sbin/update-initramfs processes this folder:

/etc/initramfs/post-update.d/

This folder could be important.

EFIStub - Debian Wiki mentions /etc/initramfs/post-update.d/zz-update-efistub

Calling that a lead.

Due to these unknown unknowns I very much think better use the Debian defaults for update-initramfs vs mkinitramfs. If we’re lucky it would even solve EFI issues.

Could you please compare functional EFI boot (iso and/or installed) vs failed EFI boot folder /etc/initramfs-tools? Maybe also /etc/grub.d/?

[HulaHoop]

Change ‘kvm’ to:
<domain type='qemu'>

Remove:

  <cpu mode='host-passthrough' check='none'/>

  <pvspinlock state='on'/>

[Patrick]

@HulaHoop

Change ‘kvm’ to:
<domain type='qemu'>

Remove:

  <cpu mode='host-passthrough' check='none'/>

  <pvspinlock state='on'/>

Done in whonix-libvirt git master.

[tempest]

so far, this is working great. here’s some of the issues i ran into, most being minor:

1. on a couple laptops that need a synaptics driver, tap-to-click on a touchpad isn’t an easy configuration option. no, this is not a whonix problem. it’s a documented debian buster issue with xfce4 that is fixable with dropping a config file into /etc/apt/xorg.conf.d/. as release gets closer to final, it may be an issue worth addressing for user friendliness.

Activate tap to click on touchpad?

2. both the gateway and the workstation appear to be configured to be best viewed in fullscreen, where it will scale to the native resolution. this could potentially lead to confusion with a user switching between windows and mistaking the gateway for the workstation. is it worth considering some type of visual distinguishment between the two?

Aside from those two things, no real usability complaints. the installation was straightforward and painless. one thing to be aware of is, on an old lower end dualcore laptop with about 2 gigs of ram, running whonix host from a usb drive with usb2 protocol, caused some various thrashing issues and anomalies. i used the various known commands out there to tweak the journaling/disk writes on the usb drive partition. but, on first boot of the whonix workstation vm, the machine appears to go into a lock state. eventually, mouse control comes back, but then virt-manager says qemu is disconnected, until eventually all the vm windows and virt-manager closes. now, this was not a huge issue since, upon opening virt-manager again, both the gateway and workstation vms were running and they could be opened to continue as usual. i don’t believe there is any applicable project fix that can be done here. i offer it as a consideration for when minimum hardware requirements are addressed.

for the most part, so far, so good. honestly, i’m really excited for “whonix host.” it simplifies so much that, in the past, has taken a lot of pages to document for people.

[onion_knight]

@Patrick

Due to these unknown unknowns I very much think better use the Debian defaults for update-initramfs vs mkinitramfs . If we’re lucky it would even solve EFI issues.

Using update-initramfs fails in Calamares installer due to the fact that the installed target still has live-boot related packages (by choice and by design, to allow live-mode in the installed target).

@Patrick

Could you please compare functional EFI boot (iso and/or installed) vs failed EFI boot folder /etc/initramfs-tools ? Maybe also /etc/grub.d/ ?

I’ll try and look at that again.

[onion_knight]

Great, thanks for your review!

@tempest

both the gateway and the workstation appear to be configured to be best viewed in fullscreen, where it will scale to the native resolution. this could potentially lead to confusion with a user switching between windows and mistaking the gateway for the workstation. is it worth considering some type of visual distinguishment between the two?

Host, gw and ws should be visually distinguishable as of now: greyish background for the host, dark blue for the gw, and greenish for the ws.

@tempest

on an old lower end dualcore laptop with about 2 gigs of ram, running whonix host from a usb drive with usb2 protocol, caused some various thrashing issues and anomalies. i used the various known commands out there to tweak the journaling/disk writes on the usb drive partition. but, on first boot of the whonix workstation vm, the machine appears to go into a lock state. eventually, mouse control comes back, but then virt-manager says qemu is disconnected, until eventually all the vm windows and virt-manager closes. now, this was not a huge issue since, upon opening virt-manager again, both the gateway and workstation vms were running and they could be opened to continue as usual. i don’t believe there is any applicable project fix that can be done here. i offer it as a consideration for when minimum hardware requirements are addressed.

Indeed, this is way below the minimal requirement to run Whonix-Host. I would not expect a smooth experience with less than 4gigs of RAM, see:
https://phabricator.whonix.org/T976

[tempest]

@onion_knight

Great, thanks for your review!

thanks for your work.

Host, gw and ws should be visually distinguishable as of now: greyish background for the host, dark blue for the gw, and greenish for the ws.

i’ll check again. may be worth considering the color choices because it didn’t stand out. perhaps “black” for the gateway?

Indeed, this is way below the minimal requirement to run Whonix-Host. I would not expect a smooth experience with less than 4gigs of RAM, see:
⚓ T976 Whonix-Host Low RAM Tests

it is. however, i’d gotten to work on the same machine in the past without this issue. however, that may have been with stretch as the host, gnome as the de and vbox as virtual machine base. like i said, i don’t think it’s a project issue. simply sharing. if you want, i have a “nonfree” based buster installed on a usb2 drive. could install the kvm packages for whonix on there and see if the same issue occurs. but, i doubt it’s worth it.

[Patrick]

@onion_knight

Using update-initramfs fails in Calamares installer due to the fact that the installed target still has live-boot related packages (by choice and by design, to allow live-mode in the installed target).

update-initramfs isn’t “totally destroyed”.

ls -la /usr/sbin/update-initramfs*

lrwxrwxrwx 1 root root 26 Dec 7 2017 /usr/sbin/update-initramfs → /bin/live-update-initramfs
-rwxr-xr-x 1 root root 7332 Jul 27 2019 /usr/sbin/update-initramfs.orig.initramfs-tools

/usr/sbin/update-initramfs was modified by pacakge live-tools to be a symlink to /bin/live-update-initramfs

The orignal update-initramfs is still available as /usr/sbin/update-initramfs.orig.initramfs-tools

Could you please have a look at both scripts? Maybe we’ll find the best way to deal with this. Maybe some way to “trick” /bin/live-update-initramfs into calling /usr/sbin/update-initramfs.orig.initramfs-tools (it does that under some conditions).

We can to undo and restore the original update-initramfs or use the original update-initramfs. Full details here: Whonix-Host Operating System (OS) ISO - #231 by Patrick

Either before running the calamares installer:

sudo unlink /usr/sbin/update-initramfs
sudo cp /usr/sbin/update-initramfs.orig.initramfs-tools /usr/sbin/update-initramfs

That might work well enough as a workaround. Something similar could be applied during the build process.

Or modify main.py.dist to run /usr/sbin/update-initramfs.orig.initramfs-tools (with paramater -u? similar to default).

Maybe VirtualBox can be a good tool to conveniently test EFI booting during development? Never tried that yet. Not even with Debian.

Also as weird as that might seem, I guess I am going to add some opt-in debug option to install VirtualBox guest additions on on Whonix-Host KVM iso because that would help during development.

[onion_knight]

@Patrick

Or modify main.py.dist to run /usr/sbin/update-initramfs.orig.initramfs-tools (with paramater -u ? similar to default).

Default is update-initramfs -k all -c -t
→ for all installed kernels
→ create new initramfs
→ last flag I have actually no idea!! (-t)

But @Patrick you were right!

Simply update-initramfs by update-initramfs.orig.initramfs-tools in the original main.py script did the trick!

Should I modify the git file accordingly?

[Patrick]

onion_knight via Whonix Forum:

But @Patrick you were right!

Did this help with EFI issues?

Simply update-initramfs by update-initramfs.orig.initramfs-tools in the original main.py script did the trick!

Should I modify the git file accordingly?

Yes, please. That change seems sane either way. Closer to defaults. More
reliable, future proof.

[onion_knight]

@Patrick

Did this help with EFI issues?

Didn’t test it yet, but I doubt it.

@Patrick

Yes, please. That change seems sane either way. Closer to defaults. More
reliable, future proof.

Done.

Update main.py.dist

[Patrick]

Thanks! Merged.

[Patrick]

@tempest

on a side note, maybe “qemu-utils” should be installed in advance on whonix host with the distro image?

I guess so.

[Patrick]

add qemu-utils to whonix-host-xfce-kvm-freedom

[Patrick]

tempest via Whonix Forum:

so far, this is working great. here’s some of the issues i ran into, most being minor:

1. on a couple laptops that need a synaptics driver, tap-to-click on a touchpad isn’t an easy configuration option. no, this is not a whonix problem. it’s a documented debian buster issue that is fixable with dropping a config file into /etc/apt/xorg.conf.d/. as release gets closer to final, it may be an issue worth addressing for user friendliness.

debian - Activate tap to click on touchpad? - Unix & Linux Stack Exchange

Could you send a pull request against
GitHub - Kicksecure/usability-misc: Misc usability improvements please?

for the most part, so far, so good. honestly, i’m really excited for “whonix host.” it simplifies so much that, in the past, has taken a lot of pages to document for people.

Yay!

[HulaHoop]

@Patrick

<cpu mode='host-passthrough' check='none'/>

Note that the libvirt xml file is just

<cpu mode='host-passthrough'/>

before it gets imported. So this should be changed if this operation is applied to an already imported VM vs the files shipped and unzipped.

[Patrick]

@HulaHoop

So this should be changed if this operation is applied to an already imported VM

Doing something about already imported VMs is not implemented.

/usr/lib/whonix-libvirt/install is simplistic.

/usr/lib/whonix-libvirt/install started during boot (whonix-libvirt-install.service) after libvirt.

• during Whonix ISO live boot
• during first boot of Whonix-Host installed (live [1] or persistent)

And /usr/lib/whonix-libvirt/install is started only once. Because it creates a done file /var/lib/whonix-libvirt/install.done and if that done file exists it won’t run again. That is to get the initial setup done but from then not interfere with the user.

@HulaHoop

vs the files shipped and unzipped.

The iso itself is compressed but the contents of the iso aren’t compressed.

@HulaHoop

Note that the libvirt xml file is just

<cpu mode='host-passthrough'/>

before it gets imported.

/usr/lib/whonix-libvirt/install expects libvirt xml files in folder /usr/share/whonix-libvirt/xml. If QEMU is detected [2], it applies these changes to temporary files before importing the xml files for the first time.

If someone upgrades from non-KVM capability to KVM capability, already imported (manually or at first boot) VMs aren’t automatically upgraded to be using KVM. Maybe if KVM failed to be detected there should be a one time popup pointing that out? Warn against performance issues and future non-auto-upgrade to KVM? Warn against security too? Is QEMU considered less secure than KVM in the age of spectre / meltdown?

---

[1] only if no previous persistent boot.
[2] or better said if KVM is not detected.

[onion_knight]

I would like to tackle some networking issues/questions I didn’t really pay attention to until now (thus I don’t know if the below described behavior is recent or has always been this way on Whonix-Host).

On installed Whonix-Host in KVM there is a (expected) conflict between the host (i.e. the physical machine) and the guest (i.e. the KVM Whonix-Host VM) virtual virbr0 NAT interfaces as both by default use 192.168.122.0/24.

Problem: I cannot bring up eth0 on installed KVM Whonix-Host even after disabling virbr0:

user@host:~$ sudo ifup eth0
No DHCP client software found!
ifup: failed to bring eth0

Is it related to dhcpcanon which has its own syntax? (btw I still don’t understand why we insist on using dhcpcanon instead of network-manager for DHCP).

Then I noticed that eth0 is defined in /etc/network/interfaces.d/30-kicksecure

auto eth0
iface eth0 inet dhcp

This raises a (maybe very naive and stupid) question:
Why do we need to define the default Ethernet interface on Whonix-Host (and using the old naming system instead of new predictable ones)? Isn’t is supposed to be automatically taken care of by NetworkManager?