Hacker News Reader

Comment by zby | Hacker News Reader

I am still impressed by QubesOS track and I use it for my dedicated 'financials' laptop.

IMHO the thing that is holding back QubesOS is the lack of hardware acceleration for graphics - maybe now when dual monitor setups are getting popular this could be a workaround for the security considerations?

View on HN

I dropped QubesOS once exactly for that reason in the past but now I’m running it again on a separate computer.

Even with all its drawbacks, there is something really nice about being able to run different applications over Tor, VPN or plain internet simultaneously, the ability to isolate non-safe binaries and being able to backup your VMs easily.

I wish a similar distro would be made based on KVM so that the standard kernel could be used. It would be great for compatibility.

> being able to run different applications over Tor, VPN or plain internet simultaneously, the ability to isolate non-safe binaries and being able to backup your VMs easily.

These are all possible using light containers. For example, on FreeBSD I will spin up a jail which runs wireguard, and then I'll bridge that to another a jail. That 2nd jail is running entirely off wireguard without any other way to access the network. Since it is a jail, it is isolated. And backing up is as simple as a zfs snapshot and zfs send. I assume the same is possible on Linux.

I would argue non-safe binaries are not safe in a container either. And even with full VMs, there have been an embarrassing number of escape exploits over the years.

> I wish a similar distro would be made based on KVM

There is an Issue for that: https://github.com/QubesOS/qubes-issues/issues/7051

This is sort of a solved problem with virtio native context. You can just run mesa driver in the virtual machine and proxy it's ioctl calls to host kernel gpu driver.

I'm pretty sure all the major GPU drivers in mesa now supports this feature.

Wonder why QubesOS hasn't adopted this yet.

They use Xens pci passthrough, you can setup a pci device to be assigned to a vm.

The vm runs it's own driver and has direct access to the device, you typically have to hide the device from dom0 for it to work flawlessly and hardware support is required. But I believe the kernels do not interact with each other in a direct way.

I used to have crashes on trying to restart a vm with a pci device attached probably related to resetting the device. But they seem to have resolved now days.

Hardware graphics acceleration can work, it just needs a bit of fiddling and opens a few attack vectors. I don't legitimately know if there has ever been a viable attack through a shared pci device though.

Problem is not that nobody wants to do it, it is that GPU stack is exactly the kind of enormous driver surface Qubes exists to keep away from dom0. Second monitor does not really change that, somebody still has to trust the driver.

The driver could run in a VM and only display applications from that VM or a subset of VMs.

Most GPU drivers are an order of magnitude more complex than a CPU kernel.

There is also the fact most GPU are a bodged on architecture, and fundamentally impossible to really secure in the case of CUDA rootkits.

Fast, but a bad design. This is why we can't have nice things. =3

Reply on news.ycombinator.com