The cpuid problem is an unauthorized information leakage problem. Any unprivileged process (in a VM or not) can read cpuid info. Many Whonix users and also users of other projects appreciate the significance of this problem. I know another category of more “institutional” users who are not cognizant of how proprietary software behaves, are oblivious to the cpuid problem, and would also find the problem concerning (if they were informed of it).
The CPU model is the information vulnerable to leakage that is of primary concern. While yes, some CPU fingerprinting can be done with listing of CPU features and cache layout information, a execution context optimized for anti-fingerprinting does not need to expose all CPU features and/or cache layout.
At one specific business I support, we have for two specific clients a hard business dependency (yielding to the client) on Microsoft Word. There is a steady stream of data exiting the organization from where Microsoft Word runs. That data must be only human-generated data and any machine-generated metadata must have a value of substance equal to null. In addition to the other bits of Microsoft Word and their specific respective mitigation, cpuid is an information disclosure vulnerability I would like to make sure that Microsoft Word (or any other foreign software) can not exploit and bleed out.
The only currently known way to mitigate the cpuid problem is to run an x86_64 emulator in userspace because the relevant opcode(s) for cpuid must be intercepted. If someone else can describe this in a better (or more correct) way, please do.
On Intel and AMD, virtualization will always expose the unprivileged cpuid query functionality to processes in a guest OS, as far as we know today at least. Maybe someone will figure out how to make “unauthorized” microcode updates happen. Maybe someone will show how to mitigate cpuid with a hypervisor. Until then, running an x86_64 emulator in userspace is the only currently known way.
Qemu can run x86_64 in only software and also not expose cpuid. Maybe Xen can too (maybe someone who is more familiar with Xen can chime in here). Some x86_64 in userspace examples are blink and bochs.
For some software, a one half or even one third of runtime speed is an acceptable tradeoff for immunity to the cpuid problem. I think usable templates for Debian, Fedora, maybe some others for an anti-fingerprint qube runtime, even if it runs slower, should exist.
I don’t know if this can be used to disable CPUID.
And even if possible, this is not a reliable approach. These vulnerabilities are considered security issues by hardware and firmware vendors. The only option would be to buy vulnerable hardware (to avoid buying hardware that is currently not supporting to run unauthorized microcode) and to abstain from installing BIOS updates (which would prevent unauthorized microcode). Not installing BIOS updates can lead to other security issues.
This is a far to messy situation for anyone to start maintaining a project that disables CPUID through unauthorized microcode.
The hypervisor can control the CPUID, you don’t need hacked microcode.
On Proxmox, you can select the CPU family, I don’t see why it would be impossible to make the same feature for Xen. Changing the CPUID has very real consequences, unless you select a compatible CPU family you can’t start the VM. As an example, my Ryzen 5 Zen 2 CPU will not start as an Athlon, Opteron, or Phenom, but it can start as EPYC.
Also, highly optimized applications can crash when the expected CPU architecture doesn’t match the physical hardware, I have seen this happen with databases.
To me, the idea of changing the CPUID on Qubes OS seems like a waste of time/resources. The CPUID is not a unique identifier, the difference between someone knowing you are using a specific CPU family or specfic CPU model is not significant.
Quick technical input: at least on Intel VT-x, the CPUID instruction is (usually) trapped and emulated by the VMM. See Intel’s SDM vol3 Appendix C: exit reason #10. Typically the VMM would execute the CPUID instruction in host (root) context and filter the registers before returning to the guest. There is no need to patch the microcode (!) to achieve something like that. I don’t know what Xen actually does though, I haven’t checked the sources.
Now about returning a custom ID for the host CPU that would actually increase your fingerprints (your system would be more unique, like potentially very very unique if you return “L33tm4ch1n3” instead of “GenuineIntel”). But I suppose you would instead return (fake) the most common CPU.