|
For reference, this kind of problem is avoided on QubesOS (another, Xen-based, hypervisor system) by routing all traffic through another VM that entirely owns the network hardware. I run my Wireguard on that VM. The host OS image, dom0, also routes its network traffic through that VM, to get updates. (It doesn't trust the updates it gets that way; it checks their signatures.) QubesOS provides another VM as a dedicated firewall just to route untrusted guests' traffic through, first. With enough cores, it all runs fast. For many users, all guest VMs are untrusted. Dodgy programs like browsers get their own VMs, spun up as needed and discarded. That does take a fair bit of RAM; my maxed-out 16GB laptop notices the strain. But memory is cheap these days, if you have the sockets to put it in. As an aside, dom0 also mediates access to the UI hardware, including display RAM. Each guest can run X, but its pixels are copied to the real display by dom0. Guest VMs can't see one another's pixels or input traffic. dom0 also mediates access to audio and video streams, and can route them to selected VMs as needed. (In a future release they plan to manage the display in its own VM, because display drivers are a big attack surface of their own.) It all works astonishingly well. Incidentally, this model of a hypervisor with all the user-level OSes as VMs, including the host, originated at IBM in the 1960s. That worked in a megabyte or two, which seemed like a lot at the time. |