Spoofing the CPU name

I think qubes should obscure the cpu name by default and maybe some of the cpuid info.

This has been discussed quite a bit on both the qubes and whonix side, lots of valuable info is on their wiki here and also mentioned on kicksecure here.

I agree that no matter what is done - there is no way to prevent a motivated attacker with local code execution in a qube from determining the cpu model. Hiding the name and feature set can be overcome by doing micro-benchmarks and testing instructions from each x86 extension set to see if it matches the reported feature set. However unfortunately there are lots of applications that are grabbing the kernel version and cpu name as part of their telemetry/device information.

For many users here, the combination of linux kernel version with qubes in the name + your cpu model is a globally unique identifier and this is collected by lots of applications. Everything from zoom to telegram and probably more is collecting low hanging device information like this and it makes it impossible to maintain separate identities in separate qubes even with whonix workstation. None of the applications collecting this stuff for their telemetry are going to develop a cpu micro-benchmarking and feature set enumeration module so changing the xen defaults for everyone to something like KVM’s “QEMU Virtual CPU version 2.1.2” will improve everyone’s privacy. I’m not sure if it’s possible but making it a flag that defaults to on but is per vm would be nice in-case there are rare situations where someone wants to pass the real cpu name into a HVM for some reason.

1 Like

You are not the first to suggest this, you can use the search function on the forum and github for more information.

The one reason for not changing it is that xen doesn’t support it, and the id is used by your system. If you pick an id that isn’t compatible with your cpu, it might result in stability issues.

Yes I know many parts of the system query cpuid and use the feature set to decide what code to execute. If you spoof the feature set and lie about having avx512 then things will try to use that, throw UD and break. I’m mainly focused on the process name string which isn’t “used” by anything in a way that would break the system. Xen might not support it out of the box but it is possible to change it from the hypervisor like KVM does, I don’t think it would be too complex of a patch.

Isn’t the only string for Intel CPUs “GenuineIntel” and everything else is extracted from the id opcodes?

To my knowledge the only way the vm can get the cpu name is from cpuid with the 0x80000002,3,4 leafs. If you spoof that then it feeds into all the other places in the vm that cpu info appears like /proc/cpuinfo or an other APIs.

Xen already traps cpuid and handles leaf 0x0 to inject their xenxenxen string or whatever it is. Should be trivial to handle the other cases and return a generic name.

Changing the manufacturer ID doesn’t change the cpuid, which is why xen can replace GenuineIntel with XenVMMXenVMM.

The manufacturer ID is a different part and unimportant. That is the one from 0x0. It’s the extended ones 2-4 where the actual “AMD Ryzen 3 2800 2-Core Processor” string gets given to the guest. I found where it all goes down.

They have a giant struct that they store all the cpuid info in.

The brand string is further down in that struct.

They fill in this data with the x86_cpuid_policy_fill_native function.

And then whenever a guest does an 0x8000… leaf query they just copy from this buffer.

Just putting a couple lines at the bottom of x86_cpuid_policy_fill_native that overwrite the brand name would do the job - although something a bit more complex would be required to make this an optional feature you can toggle off for a specific qube if you so wish.

If all you want to do is change the model name, and don’t care about the cpuid having the real id.


You could just patch get_model_name, probably a lot easier to do it in Linux than Xen.

Patching that in the kernel version used by the guest would probably fix most instances but if there is application is using a library that does the cpuid query itself then it will see past that.

1 Like