If CPU Type is KVM64, Can a VM Still Exploit CPU Vulnerabilities on a Host with Disabled Linux Kernel CPU Patches?

[ice9]

Hi everyone,

I have a question regarding a specific security scenario in Proxmox:

Suppose the Proxmox host has Linux Kernel CPU Patches disabled.

Now, assume that the VMs are configured with CPU type = kvm64, which is a simplified and virtual CPU model without exposing most modern CPU features to the guest.

In this setup, is it still possible for a malicious or compromised VM to escape and attack the host via known CPU vulnerabilities, even though the guest is using kvm64?

In other words:

Does using KVM64 on the guest side effectively shield the host from speculative execution attacks initiated within a VM?

Or does disabling Linux Kernel CPU Patches disabled on the host still leave it exposed to certain attacks, regardless of the virtual CPU type presented to guests?

Also, how about other types like x86-64-v2-AES or x86-64-v3?

Any clarification on how much protection KVM64 offers in this context would be greatly appreciated.

 

[leesteken]

I'm convinced that the exploits don't depend on the instruction set but on the speculative out-of-order execution nature of modern CPUs. So I don't expect using older or more generic (like x86-64-v*) or 'virtual' CPU types (like kvm64 or qemu64) to fix the problem at all.
Maybe if KVM hardware virtualization is disabled for the VM and all instructions are emulated (and you'll get terrible performance), it might make a difference?
Switching between the VM and the host is one of the points where the CPUs are especially vulnerable, regardless of the configured CPU type.

I don't think you can reason yourself out of having vulnerable hardware by using VMs or hoping you don't need the mitigations. Virtualization might be one of the more lucrative targets for these kinds of exploits (from one VM to another in a cloud environment).

 

[ice9]

Thanks for the clarification

So just to confirm my understanding:
If the host doesn't have the Linux kernel CPU vulnerability patches (mitigations) installed or enabled, then even when using CPU types like kvm64 or other simplified models for VMs, the host is still potentially vulnerable to CPU-level attacks originating from a compromised VM — correct?

If you happen to have any relevant documentation or references (from Proxmox, QEMU, or KVM) that explain this behavior in more detail, I’d really appreciate it if you could share them.

Thanks again for your help

 

[guruevi]

The large caveat here is: it depends on what we are talking about. If you want to understand a specific exploit, there are tons of articles and papers out here, but we are speaking about a class of vulnerabilities, not a specific vulnerability (which there are dozens for every modern CPU out there).

In very large lines: two/multiple threads executing simultaneously or with certain predicted paths (any CPU since the Pentium) can in theory access the physical cache or portions of cache (CPU memory) of each other. Not a big deal if all programs ‘trust’ each other, bigger problem for VM, browsers etc. It has been demonstrated this can be exploited by any program that can execute code even in sandboxes like VM or browsers.

Will it affect you: depends on who you are and what you run. Is it theoretical: some of it is (for now), some of it isn’t. What’s the risk: losing encryption keys and other data.

What is the downside: on systems older than 5 years, you’ll see a small loss (a few percentage points for most workloads) of performance for Linux systems, a large loss of performance (~20%) for Windows systems that have all mitigations enabled (note: Windows by default does not enable mitigations). You also need the latest firmware including for the CPU and UEFI to enable certain mitigations, newer CPU (last 5 years) are less affected by performance losses. Across the entire class, there are both software and hardware mitigations that are required, the hardware ones such as disabling certain CPU instructions, which is what Proxmox can do, the software mitigations, baked into modern Linux kernels, but older kernels and Windows require changes to settings.