All Internet resources except the one provided by the Oracle say paravirtualization doesn’t pose a security risk. The quote from their website goes on as this:
Paravirtualization is considered a less secure guest domain type. To keep your virtualized environment safe and secure, you should prevent paravirtualized guest VMs from starting and running within Oracle VM.
This topic is relevant to me since Whonix for KVM uses a handful of virtio(paravirtualized) devices for Whonix gateway and workstation.
In my understanding paravirtualization may become a security risk as my intuition tells better instruction execution time given by paravirtualization means worsened security. How do paravirtualized VMs manage to keep VM and hypervisor domains separate if paravirtualized instructions are executed on the bare-metal level? Shouldn’t it enable all kinds of security vulnerabilities as buffer overflows to be exploited on the bare-metal level? VMs are intrinsically untrusted by the hypervisor, and allowing untrusted code to be executed with kernel-level priveleges doesn’t seem secure.
Which is true, it doesnt.
KVM is installed on the host, and Whonix is a guest OS that has its own kernel. Therefore, if the guest OS is exploited, it has no direct impact on the host OS. The host system could be threatened only if an attacker exploits a VM escape vulnerability, such as Spectre or Meltdown or so… However, the occurrence of such a threat is unrelated to whether you are using full or paravirtualization.
General security question. Unspecific to Whonix.
Needs to be resolved as per:
Out of scope for Whonix support as per Bug Reports, Software Development and Feature Requests chapter Support Request Policy in Whonix wiki.
You know, it would help if you post links to what you’re talking about to help those who will answer your questions. The hypervisor you are talking about is Oracle VM Server based on Xen, Before its current design, Xen had a full paravirtual mode for running ring 0 code on systems that didn’t support hardware virtualization, not just for I/O devices. The downside was it required the guest OS kernel to be paravirtual aware and be modified. This required more code in the TCB and was more error prone than harnessing virtualization extensions in the silicon which KVM did from day one.
As for I/O device virtualization security, paravirtual mode is the sweet spot between security and performance. Fully emulated devices are plagued with security holes because the code base is larger and their performance is much slower.Hardware Passthorugh mode exposes the baremetal IO devices to hostile code and firmware modifications. While SR-IOV devices are the virtualization aware generation of hardware, you are putting your faith and trust that the hardware vendor implementation doesn’t have security holes and is patched up to date. Personally I’ll trust the upstream QEMU team over my hardware vendor on this.