Comment by minimalist | Hacker News Reader

Comment by minimalist | Hacker News Reader

This is an amazing effort, very cool!

I'm not sure why the author is having so much pain with Qubes. Indeed the lack of GPU in guest VMs is annoying but it is possible now to assign a GPU to a HVM fairly reliably thanks to all of the VFIO/gaming-on-linux enthusiasm in the past years. Otherwise, I also find that running browsers in multiple VMs on laptop is a problem if you don't disable JS by default because modern websites have become so bloated, it's a tragedy. The LVM remark is also strange. It's very reliable for plenty of people, but there is the risk of running out of space for metadata [0]. Thin-pools for VM storage allows for some great Time-Machine-esque incremental backups also [1]. But for managing multiple development environments, Qubes is a blessing, not even including all the security benefits.

Another option for Xen fans is XCP-ng + a thin client machine for accessing the VMs. One can also use firejail+Xephyr to achieve graphical isolation [2] (not sure about Wayland).

It looks like architecture changes in Qubes future [3] may make KVM a reality.

This is still a very cool effort, I'll have to give the Wayland bits a close read.

[0]: https://github.com/QubesOS/qubes-issues/issues/3243, https://listman.redhat.com/archives/linux-lvm/2018-July/msg0...

[1]: https://github.com/tasket/wyng-backup

[2]: https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki's_EFI_Instal...

[3]: https://www.qubes-os.org/news/2020/03/18/gui-domain/

The Qubes people don't recommend doing GPU passthrough because of the security implications.

As for the OP, I feel like if somebody cares about security, they shouldn't be doing any of this. Trying to come up with some self-designed hodgepodge of things isn't really enough security-wise, even if you do use VMs, and I'd find it hard to trust something like this as a platform to do anything important on.

> The Qubes people don't recommend doing GPU passthrough because of the security implications.

Why? DMA?

I don't know details. I was thinking about doing GPU passthrough myself, but whenever developers chimed in on any posts about the topic, this is essentially what they said.

Some links I remember going through:

https://www.qubes-os.org/doc/device-handling-security/#pci-s...

> Additionally, Qubes restricts the config-space a VM may use to communicate with a PCI device. Only whitelisted registers are accessible. However, some devices or applications require full PCI access. In these cases, the whole config-space may be allowed. You’re potentially weakening the device isolation, especially if your system is not equipped with a VT-d Interrupt Remapping unit. This increases the VM’s ability to run a side channel attack and vulnerability to the same. See Xen PCI Passthrough: PV guests and PCI quirks and Software Attacks on Intel VT-d (page 7) for more details.

https://security.stackexchange.com/questions/162122/gpu-pass...

"Clarifications on GPU security": https://groups.google.com/g/qubes-devel/c/MeLYpHyLRHQ

See also: https://www.qubes-os.org/faq/#can-i-run-applications-like-ga...

But the fact is, even if you are doing GPI passthrough in Qubes, it's much more secure than running any other system.

Basically, yes.

Theoretically, all modern systems have IOMMUs, which are supposed to be able to allow an operating system (or hypervisor in this case) to restrict what a device can do.

In practice, IOMMUs can't be trusted, for two reasons.

First, the implementations (i.e., the actual hardware) are frequently full of unpatchable security holes. It's not just the CPUs themselves that need to be correct; every chip in the PCI chain has to DTRT from a security perspective or risk opening up a vulnerability.

Secondly, particularly with GPUs, many systems have 'magic backdoors' that side-step the IOMMU systems completely. Frequently this is to make certain operations "faster" or "easier".

Basically, unless you have done your own audit and testing of the hardware you own (or someone you trust has done the same thing), you have to more or less assume that a malicious guest with control of a physical device could break out of the system.

In Xen's SUPPORT.md document, we very carefully tried to balance this:

Because of hardware limitations (affecting any operating system or hypervisor), it is generally not safe to use [PCI passthrough] to expose a physical device to completely untrusted guests. However, this feature can still confer significant security benefit when used to remove drivers and backends from domain 0 (i.e., Driver Domains).

"The Qubes people" have a product to develop and maintain. They aren't the single highest authority on secure desktop setups.

Security isn't a black or white issue. There are levels of security. Many tech people want something better than the (very insecure) standard setup on Linux/Windows, but they don't want the Qubes straight-jacket. This means they search or develop alternatives and that is overall a good thing.

Reply on news.ycombinator.com