> both Linux and macOS (but not Windows AFAIK) allow unprivileged processes to use at will
Only sort of true on Linux. Most Linux distributions make /dev/kvm non-world-accessible because it's a good source of security issues (see e.g. http://www.ubuntu.com/usn/USN-2417-1/ ); the KVM driver isn't quite hardened against people who are trying to compromise the host kernel instead of actually make a VM. PolicyKit often gives access to the current logged-in desktop user, but that's precisely because those processes aren't quite unprivileged (e.g., processes running as the logged-in desktop user can usually shut down the machine or prevent it from sleeping without authentication).
Which leads to an interesting point: doing this in software, as Vx32 and Native Client do, fails safe. Since it's just regular user code, it can't possibly do things that regular user code can't do, and you can belt-and-suspenders it with an extremely tight seccomp policy on the emulator (as Chrome does). If you do this at the OS level via seccomp directly, and the OS gets it wrong, it fails open (e.g., CVE-2009-0835), but still shouldn't allow execution of non-user-mode code. If you do this at the CPU level via privilege rings, the CPU isn't very likely to get it wrong -- but if it does it fails very open (i.e., into a privileged ring) and is the hardest to patch.
It's absolutely not true that we don't care about KVM host vulnerabilities. KVM survived a good deal of fuzzing with only a handful of trivially fixed NULL-pointer dereference oopses found (including one which turned out to be a bug in a completely different part of the kernel) and no privilege escalations.
Most distros actually make /dev/kvm world-accessible; you are confusing that with virt-manager requiring PolicyKit authentication by default (that's because networking is better integrated if libvirtd runs as root), but for example GNOME Boxes doesn't
That must be a relatively recent change, then - several years ago I think everyone did care quite as much, there just were more vulnerabilities. I'm not insinuating this is because of anyone not caring. :-) It was just a fact that there were a bunch of CVEs.
For instance, Debian stable makes it 664 root:kvm, and a bug I opened a bunch of years ago to change that got wontfixed: https://bugs.debian.org/640328 Is it time to request reconsideration?
Only sort of true on Linux. Most Linux distributions make /dev/kvm non-world-accessible because it's a good source of security issues (see e.g. http://www.ubuntu.com/usn/USN-2417-1/ ); the KVM driver isn't quite hardened against people who are trying to compromise the host kernel instead of actually make a VM. PolicyKit often gives access to the current logged-in desktop user, but that's precisely because those processes aren't quite unprivileged (e.g., processes running as the logged-in desktop user can usually shut down the machine or prevent it from sleeping without authentication).
Which leads to an interesting point: doing this in software, as Vx32 and Native Client do, fails safe. Since it's just regular user code, it can't possibly do things that regular user code can't do, and you can belt-and-suspenders it with an extremely tight seccomp policy on the emulator (as Chrome does). If you do this at the OS level via seccomp directly, and the OS gets it wrong, it fails open (e.g., CVE-2009-0835), but still shouldn't allow execution of non-user-mode code. If you do this at the CPU level via privilege rings, the CPU isn't very likely to get it wrong -- but if it does it fails very open (i.e., into a privileged ring) and is the hardest to patch.