Spoofing the CPU name

fekah79055 · June 7, 2023, 9:48am

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.

renehoj · June 7, 2023, 10:06am

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.

fekah79055 · June 7, 2023, 10:13am

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.

renehoj · June 7, 2023, 10:20am

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

fekah79055 · June 7, 2023, 10:41am

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.

renehoj · June 7, 2023, 11:04am

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

fekah79055 · June 7, 2023, 11:21am

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.

github.com

xen-project/xen/blob/f5c1a6374aae8be471b895a43359dcff355577f5/xen/include/xen/lib/x86/cpuid.h#L109


      
          * the entries in basic which sub-unions hang off of.)
          */
          #define CPUID_MAX_SERIALISED_LEAVES                     \
             (CPUID_GUEST_NR_BASIC +                             \
              CPUID_GUEST_NR_FEAT   - !!CPUID_GUEST_NR_FEAT +    \
              CPUID_GUEST_NR_CACHE  - !!CPUID_GUEST_NR_CACHE +   \
              CPUID_GUEST_NR_TOPO   - !!CPUID_GUEST_NR_TOPO +    \
              CPUID_GUEST_NR_XSTATE - !!CPUID_GUEST_NR_XSTATE +  \
              CPUID_GUEST_NR_EXTD + 2 /* hv_limit and hv2_limit */ )
          
          
struct cpuid_policy
          {
          #define DECL_BITFIELD(word) _DECL_BITFIELD(FEATURESET_ ## word)
          #define _DECL_BITFIELD(x)   __DECL_BITFIELD(x)
          #define __DECL_BITFIELD(x)  CPUID_BITFIELD_ ## x
          
          
   /* Basic leaves: 0x000000xx */
             union {
                 struct cpuid_leaf raw[CPUID_GUEST_NR_BASIC];
                 struct {
                     /* Leaf 0x0 - Max and vendor. */

The brand string is further down in that struct.

github.com

xen-project/xen/blob/f5c1a6374aae8be471b895a43359dcff355577f5/xen/include/xen/lib/x86/cpuid.h#L270


      
          uint32_t raw_fms, /* b */:32;
          union {
              uint32_t e1c;
              struct { DECL_BITFIELD(e1c); };
          };
          union {
              uint32_t e1d;
              struct { DECL_BITFIELD(e1d); };
          };
          
          
uint64_t :64, :64; /* Brand string. */
          uint64_t :64, :64; /* Brand string. */
          uint64_t :64, :64; /* Brand string. */
          uint64_t :64, :64; /* L1 cache/TLB. */
          uint64_t :64, :64; /* L2/3 cache/TLB. */
          
          
/* Leaf 0x80000007 - Advanced Power Management. */
          uint32_t /* a */:32, /* b */:32, /* c */:32;
          union {
              uint32_t e7d;
              struct { DECL_BITFIELD(e7d); };

They fill in this data with the x86_cpuid_policy_fill_native function.

github.com

xen-project/xen/blob/f5c1a6374aae8be471b895a43359dcff355577f5/xen/lib/x86/cpuid.c#L173


      
              BUILD_BUG_ON(ARRAY_SIZE(p->xstate.raw) > 63);
          
          
    for ( i = 2; i < min_t(unsigned int, 63,
                                     ARRAY_SIZE(p->xstate.raw)); ++i )
              {
                  if ( xstates & (1ull << i) )
                      cpuid_count_leaf(0xd, i, &p->xstate.raw[i]);
              }
          }
          
          
/* Extended leaves. */
          cpuid_leaf(0x80000000, &p->extd.raw[0]);
          for ( i = 1; i <= MIN(p->extd.max_leaf & 0xffffU,
                                ARRAY_SIZE(p->extd.raw) - 1); ++i )
              cpuid_leaf(0x80000000 + i, &p->extd.raw[i]);
          
          
/* Don't report leaves from possible lower level hypervisor, for now. */
          p->hv_limit = 0;
          p->hv2_limit = 0;
          
          
x86_cpuid_policy_recalc_synth(p);

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

github.com

xen-project/xen/blob/f5c1a6374aae8be471b895a43359dcff355577f5/xen/arch/x86/cpuid.c#L930


      
          
          
    /*
               * Fallthrough.
               *
               * Intel reserve up until 0x4fffffff for hypervisor use.  AMD reserve
               * only until 0x400000ff, but we already use double that.
               */
          case 0x40000100 ... 0x400001ff:
              return cpuid_hypervisor_leaves(v, leaf, subleaf, res);
          
          
case 0x80000000 ... 0x80000000 + CPUID_GUEST_NR_EXTD - 1:
              ASSERT((p->extd.max_leaf & 0xffff) < ARRAY_SIZE(p->extd.raw));
              if ( (leaf & 0xffff) > min_t(uint32_t, p->extd.max_leaf & 0xffff,
                                           ARRAY_SIZE(p->extd.raw) - 1) )
                  return;
          
          
    *res = array_access_nospec(p->extd.raw, leaf & 0xffff);
              break;
          
          
default:
              return;

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.

renehoj · June 7, 2023, 11:55am

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

https://github.com/torvalds/linux/blob/master/arch/x86/kernel/cpu/common.c

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

fekah79055 · June 7, 2023, 11:58am

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.

fsflover · June 7, 2023, 1:26pm

github.com/QubesOS/qubes-issues

Stop telling VMs the exact physical CPU model in the computer

opened 12:21AM - 21 Aug 15 UTC

closed 11:45PM - 17 Oct 18 UTC

qubesuser

T: enhancement C: core C: Xen privacy R: won't do

Currently Qubes lets VMs execute CPUID and get the exact model and microcode rev…ision of the physical CPU installed in the system. This is bad for anonymity and unexpected. Already discussed in https://groups.google.com/forum/#!msg/qubes-devel/Q8h-RGH5YoA/fzWbi7c-kfoJ but there seems to be no open issue, and it's a critical issue at least for anonymous VMs. Possible solutions: 1. Run all VMs in Xen PVHVM mode, fix libvirt so that it allows to set the CPUID for Xen and do so 2. Run all VMs in Xen PVH mode, fix Xen so that CPUID hiding works in PVH mode and fix libvirt as well to support PVH and allow to set CPUID 3. Replace Xen with KVM and then it just works with no additional effort The CPUID chosen should be the default libvirt one for the physical CPU microarchitecture (i.e. one for Skylake, one for Haswell, one for Sandy Bridge, etc.) which allows using all CPU instruction set extensions while not giving any more information and should be changeable to a less featureful one (Core 2 or Athlon 64) for increased anonymity if desired. Ideally Qubes should wait until a few months have passed from the release of a new CPU architecture before it starts advertising it by default, to ensure that the anonymity set is big enough, and it should also wait a random amount of time before changing it on upgrades, to avoid leaking the exact time the user installed the new CPU or changed computers. It would also be nice to look at whether it's possible to prevent applications indirectly detecting the size of the cache, size of TLBs, the speed of the CPU and other characteristics, although it may not be practical to avoid those.