Live data from Hacker News

Qubes-Lite with KVM and Wayland

roscidus.com

21–30 of 52 posts

Re: Qubes-Lite with KVM and Wayland

#21
post #4

I used qubes for a while, but found it kind of cumbersome to do most things, and I never got over the hump. Since then I've been using proxmox, and I'm at the point where I don't use the gui anymore, I just do everything from the command line. You can do VM things (like run macos in a vm), but I do most things in lxc containers. It would be kind of nice if proxmox had something like a Dockerfile, but with local conta…

I tried running proxmox on my server for a while but I found it was more complex to do everything and I wasn't gaining any benefits from it since it looked very enterprise and multi machine focused. These days I use fedora coreos with podman/docker. I'm trying out virtual machines using libvirt and then virt manager on my desktop for control but I have not been able to find a way to do bridged networking.

Re: Qubes-Lite with KVM and Wayland

#22

Earlier quoted context omitted.

That "security issue with Wayland" is really loading an untrusted .so file from your home directory, which is exactly what running apps in KVM VMs instead (as the article proposes) would fix. So yes, it's a good idea!

In addition, the author states that similar techniques would also work on Windows and Mac, and any platform without sandboxing... which would include most installations of X, unless there's something I'm missing.

All installations of X. X has no sandboxing. What most of these clickbait articles or concepts fail to mention is that at the very worst, you can get the same level of access that was possible before the sandboxing was added.

If an app has write access to your home folder, it has root. But with flatpak and portals, its realistic that direct home dir access will no longer be a thing for most apps.

Re: Qubes-Lite with KVM and Wayland

#23
I have been using Qubes for a couple of years. I was surprised at his description of his experience. I run it on an ASUS 4-core skylake laptop which has Intel integrated graphics on a 4k screen, and an NVidia thing I keep powered off. The only compatibility problems I find are that (1) ASUS BIOSes and UEFI only just barely tolerate one another, and (2) palm suppression on the touchpad doesn't work. I mapped a key to toggle the touchpad on and off. (It probably would work right with a newer dom0.)

But I haven't seen anything slow. I even play 4k full-screen video in a VM, which does burn 3 cores. I have it maxed out at 16GB of RAM, which is only just barely enough, with ZRAM swap enabled. It allows a VM, when I ask, access to the built-in microphone and camera, as needed, and takes them back. Wifi works, audio works. I keep an external 4k monitor plugged in, and that works. The touch screen can be made to work with trivial fiddling.

I was surprised to find him presenting Wayland code that looked like bad C, but is described as C++. The only C++ish thing about it was using static_cast(e) instead of C-like (T)e. It is not encouraging to find such bad code in a new-ish project (you can lead a horse to water...). Good C++ code would look a lot like his OCaml code.

The only thing I have never got to work, at all, is clipboard operations between VMs. It announces it's doing something with various clipboards, but nothing apparent ever happens.

I would rather see the dom0 running NixOS than ancient Fedora.

Re: Qubes-Lite with KVM and Wayland

#24

Earlier quoted context omitted.

In addition, the author states that similar techniques would also work on Windows and Mac, and any platform without sandboxing... which would include most installations of X, unless there's something I'm missing.

All installations of X. X has no sandboxing. What most of these clickbait articles or concepts fail to mention is that at the very worst, you can get the same level of access that was possible before the sandboxing was added. If an app has write access to your home folder, it has root. But with flatpak and portals, its realistic that direct home dir access will no longer be a thing for most apps.

Good point. I was imprecise in my wording.

I meant that most operating systems using X as the display server are not going to have application sandboxing.

I'm pretty sure the top level comment here was just FUD, although I assume it was well intentioned, just misunderstood.

Re: Qubes-Lite with KVM and Wayland

#25

Earlier quoted context omitted.

That "security issue with Wayland" is really loading an untrusted .so file from your home directory, which is exactly what running apps in KVM VMs instead (as the article proposes) would fix. So yes, it's a good idea!

In addition, the author states that similar techniques would also work on Windows and Mac, and any platform without sandboxing... which would include most installations of X, unless there's something I'm missing.

Aye, there's like 3-6 ways to inject code into applications on Windows, and then LD_PRELOAD (and equivalents) and attaching as a debugger on *NIX platforms. There's no way a display manager, audio server, etc. can protect themselves from clients from code injected into them - outside of completely disabling these functions that allow it (and certainly have valid use cases, if much less often than illegitimate ones).

Re: Qubes-Lite with KVM and Wayland

#26
virtwl.ko really is the killer app for Wayland

[Edit: virtwl.ko lets a wayland client inside a VM connect to a wayland server which is on the same machine but outside the VM].

I mean without it, all the noise about Wayland being more secure than X11 is just noise, because Wayland doesn't do remote display, so you have to allow that evil app you're scared of to run on the same machine as the compositor and all your other apps, and you can't even put it in a VM. That's less secure than being able to put it on another machine and use the network. In theory you might be able to run the evil app under another userid, but in practice this often breaks in all sorts of ways because people just don't do that very often so it exposes untested codepaths in UI/widget/GUI libraries. You can't even put the evil app in a VM -- until virtwl.ko came along.

If the Wayland folks want their security claims to no longer be laughed at they need to get virtwl.ko into mainline Linux. And get it supported by more hypervisors than just the one that comes with ChromeOS (crosvm).

I've been using sway on both my desktop and laptop for over a year now, but that doesn't mean I don't get to complain about Wayland. Since leaving X11 I did finally get everything working again (except @#*&^@%@ torbrowser), but I've been underwhelmed with the benefits gained by all the effort I had to go through in order to switch to Wayland. And I still miss remote display always working all the time without special effort from each individual app developer. Every bolt-on remote display option offered for Wayland is a flaming dumpster fire of slowness compared to X11 on the LAN or xorg-xrdp over the public Internet. And the least-flaming dumpster-fire of slowness, waypipe, has turned into abandonware.

> like many Wayland specifications, it seems to be in the process of being replaced by something else.

Funny because true.

Re: Qubes-Lite with KVM and Wayland

#28

virtwl.ko really is the killer app for Wayland [Edit: virtwl.ko lets a wayland client inside a VM connect to a wayland server which is on the same machine but outside the VM]. I mean without it, all the noise about Wayland being more secure than X11 is just noise, because Wayland doesn't do remote display, so you have to allow that evil app you're scared of to run on the same machine as the compositor and all your ot…

Can you explain what virtwl.ko is? I tried looking it up but couldn't find anything even remotely relevant when searching for that term.

Re: Qubes-Lite with KVM and Wayland

#29
post #4

I used qubes for a while, but found it kind of cumbersome to do most things, and I never got over the hump. Since then I've been using proxmox, and I'm at the point where I don't use the gui anymore, I just do everything from the command line. You can do VM things (like run macos in a vm), but I do most things in lxc containers. It would be kind of nice if proxmox had something like a Dockerfile, but with local conta…

I tried running proxmox on my server for a while but I found it was more complex to do everything and I wasn't gaining any benefits from it since it looked very enterprise and multi machine focused. These days I use fedora coreos with podman/docker. I'm trying out virtual machines using libvirt and then virt manager on my desktop for control but I have not been able to find a way to do bridged networking.

Bridged networking in libvirt can be a bit of a pain but I've found that routed works pretty well. Also - if I'm not mistaken - libvirt's netfilter firewalling isn't available on bridged networks.

Re: Qubes-Lite with KVM and Wayland

#30

virtwl.ko really is the killer app for Wayland [Edit: virtwl.ko lets a wayland client inside a VM connect to a wayland server which is on the same machine but outside the VM]. I mean without it, all the noise about Wayland being more secure than X11 is just noise, because Wayland doesn't do remote display, so you have to allow that evil app you're scared of to run on the same machine as the compositor and all your ot…

Can you explain what virtwl.ko is? I tried looking it up but couldn't find anything even remotely relevant when searching for that term.

Here's the link from the article: https://alyssa.is/using-virtio-wl/

It doesn't really have a better name. It was written by Google to allow Android apps to run inside a VM on ChromeOS. Although it does work with mainline Linux, Google is understandably not motivated to invest effort in branding virtwl.ko with a non-cryptic name, or marketing it as its own project independent of ChromeOS. AFIAK nobody outside of Google was using it until Alyssa (same person responsible for the panfrost awesomeness) got it working on Linux.

As for what it does?

Wayland clients and servers must (a) run on the same physical machine (b) as processes on the same kernel. Virtwl.ko removes requirement (b), allowing the client to be inside of a VM.

Post reply on HN