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.