Stop telling VMs the exact physical CPU model in the computer

[qubesuser]

Currently Qubes lets VMs execute CPUID and get the exact model and microcode revision 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.

[adrelanos]

This is indeed an identifier that should be hidden from compromised VMs. At least in the anonymity use case.

[qubesfreak]

exactly, and it is a huge disadvantage that qubes-os still passes the CPUID even with the latest release... please priorities this issue.

[cfcs]

Can't CPU features be enumerated by the VM regardless of what CPUID is reported?

[Bufil]

Does that critical issue still exist in 3.2-rc1 ?

[marmarek]

Does that critical issue still exist in 3.2-rc1 ?

I wouldn't call it critical, but yes.

[marmarek]

Partial libvirt support is posted: https://www.redhat.com/archives/libvir-list/2017-July/msg00050.html

[cfcs]

FWIW https://tech.mendix.com/linux/2016/08/18/xen-cpuid-masking/

[jpouellet]

This is not as simple a decision as it may appear. Yes, having a larger anonymity set would be nice, however:

1. CPUs are fingerprintable in many more ways than simply checking CPUID (for example, you can try to use features not advertised on CPUID and see what happens). There are also a hell of a lot of CPU errata, many of which can be used to fingerprint you as well. Expecting CPUID uniformity to meaningfully mitigate CPU fingerprinting is naive.

2. Historically / empirically, setting CPUID (and instruction emulation generally) has had an impact on your vulnerability to particular XSAs. See: XSA-176, XSA-190, XSA-191, XSA-195, XSA-200, XSA-204.

$ wget https://xenbits.xen.org/xsa/advisory-{26..225}.txt
$ grep -C5 -i cpuid advisory-*.txt
advisory-176.txt-==========
advisory-176.txt-
advisory-176.txt-Applying the attached patch resolves this issue.
advisory-176.txt-
advisory-176.txt-Note, however, that on hosts supporting 1Gb page mappings, for guests
advisory-176.txt:which get this capability hidden via CPUID override in their config
advisory-176.txt-file, fully correct behavior cannot be provided when using HAP paging.
advisory-176.txt-This is a result of hardware behavior, which software cannot mitigate.
advisory-176.txt-If that is a concern, such guests would need to be run in shadow paging
advisory-176.txt-mode.
advisory-176.txt-
--
advisory-190.txt-==========
advisory-190.txt-
advisory-190.txt-On Xen 4.7, not migrating across CPU vendors will avoid this
advisory-190.txt-vulnerability.  (Unless the guest grants mmio access to unprivileged
advisory-190.txt-tasks, or has been configured with a specific CPU vendor, eg using the
advisory-190.txt:xl "cpuid" configuraton option.)
advisory-190.txt-
advisory-190.txt-CREDITS
advisory-190.txt-=======
advisory-190.txt-
advisory-190.txt-This issue was discovered by Jan Beulich from SUSE.
--
advisory-191.txt-All versions of Xen are affected.
advisory-191.txt-
advisory-191.txt-However, we believe that the vulnerability cannot be exploited on Xen
advisory-191.txt-4.7 by completely unprivileged guest processes, unless the VM has been
advisory-191.txt-explicitly configured with a non-default cpu vendor string (in xm/xl,
advisory-191.txt:this would be done with a `cpuid=' domain config option).
advisory-191.txt-
advisory-191.txt-MITIGATION
advisory-191.txt-==========
advisory-191.txt-
advisory-191.txt-Running only PV guests will avoid this issue.
--
advisory-195.txt-
advisory-195.txt-On Xen 4.7 and later, the vulnerability is exposed only to guest user
advisory-195.txt-processes granted a degree of privilege (such as direct hardware
advisory-195.txt-access) by the guest administrator; or, to all user processes when the
advisory-195.txt-when the VM has been explicitly configured with a non-default cpu
advisory-195.txt:vendor string (in xm/xl, this would be done with a `cpuid=' domain
advisory-195.txt-config option).
advisory-195.txt-
advisory-195.txt-The vulnerability is not exposed to 32-bit PV guests.
advisory-195.txt-
advisory-195.txt-ARM systems are not vulnerable.
--
advisory-200.txt-
advisory-200.txt-On Xen 4.7, the vulnerability is exposed only to HVM guest user
advisory-200.txt-processes granted a degree of privilege (such as direct hardware
advisory-200.txt-access) by the guest administrator; or, to all user processes when the
advisory-200.txt-VM has been explicitly configured with a non-default cpu vendor string
advisory-200.txt:(in xm/xl, this would be done with a `cpuid=' domain config option).
advisory-200.txt-
advisory-200.txt-MITIGATION
advisory-200.txt-==========
advisory-200.txt-
advisory-200.txt-There is no known mitigation.
--
advisory-204.txt-
advisory-204.txt-On Xen 4.7 and later, the vulnerability is exposed only to guest user
advisory-204.txt-processes granted a degree of privilege (such as direct hardware access)
advisory-204.txt-by the guest administrator; or, to all user processes when the VM has
advisory-204.txt-been explicitly configured with a non-default cpu vendor string (in
advisory-204.txt:xm/xl, this would be done with a `cpuid=' domain config option).
advisory-204.txt-
advisory-204.txt-A 64-bit guest kernel which uses an IST for #DB handling will most likely
advisory-204.txt-mitigate the issue, but will have a single unexpected #DB exception
advisory-204.txt-frame to deal with.  This in practice means that Linux is not
advisory-204.txt-vulnerable.

[jpouellet]

Although, (perhaps unfortunately) we are already setting CPUID in R4 to stop advertising nested hw virt and SMAP as result of #2881. Disabling SMAP for VMs is an unfortunate workaround and I hope temporary?

[marmarek]

Although, (perhaps unfortunately) we are already setting CPUID in R4

FWIW we don't set vendor string there, only select feature bit (SMAP to 0, VMX/SVM are translated to nested_hvm xl.cfg option).

And given the list of XSAs affecting systems with custom CPUID vendor string, I think we shouldn't do this. If libvirt will support custom vendor string (it doesn't right now), we already have a mechanism to set that. But such change will not be here by default.

[Che15ea]

@andrewdavidwong Hi I believe giving empty or random hardware informaiton is very important to anonymity, by preventing rogue software from reading the hardware info in debian and fedora. It can be most effective if it's done at hypervisor level.
I wish that the model and serial number of CPU, GPU, RAM, Motherboard, Disk etc can be hidden or randomized in the request as much as possible.

[marmarek]

I wish that the model and serial number of CPU, GPU, RAM, Motherboard, Disk etc can be hidden or randomized in the request as much as possible.

AppVM has no access to most hardware info (especially - no info about your GPU, RAM, MB, disk, network, etc). What it can see, is the CPU model with various details (the CPUID instruction) that is essential for the system within the VM to function correctly (to know what instructions it can use, to know what mitigations against speculative execution should be applied etc). Masking some of of it is potentially possible (like pretending you are running on a CPU from 10 years ago), with all the disadvantages of it.

[andrewdavidwong]

I believe giving empty or random hardware informaiton is very important to anonymity, by preventing rogue software from reading the hardware info in debian and fedora.

Qubes OS does not claim to provide special privacy (as opposed to security) properties in non-Whonix qubes:
https://www.qubes-os.org/faq/#what-about-privacy-in-non-whonix-qubes

Masking some of of it is potentially possible (like pretending you are running on a CPU from 10 years ago), with all the disadvantages of it.

Since this would be "spoofing" rather than merely "hiding" the CPU info, it sounds like that would be a separate issue from this one. (It also sounds like it would come with enough disadvantages that it probably shouldn't be the default.)

[adrelanos]

Preventing a program inside a VM from finding the out CPU type is unfortunately very difficult due to the unprivileged (no root required) CPU instruction CPUID:

• https://en.wikipedia.org/wiki/CPUID
• https://forums.whonix.org/t/any-way-to-hide-cpu-info-from-whonix/11609/5

Good points on the complexity were also made earlier already. Even if CPUID was somehow controlled, CPUs can be fingerprinted in other ways to deduce the model.

@adw

Qubes OS does not claim to provide special privacy (as opposed to security) properties in non-Whonix qubes: https://www.qubes-os.org/faq/#what-about-privacy-in-non-whonix-qubes

That is an accurate description of the current situation. May I ask to clarify the interpretation of that FAQ entry? Possible interpretations:

• A) It is what it currently is. Might be improved in the future. Feature request and contributions to improve this are welcome.
• B) VM privacy features (such as hiding the CPU model) as a virtualizer/Qubes/Xen feature requests outside of Qubes-Whonix are out of scope for Qubes and will be closed/rejected?
  • And contributions would be considered? But otherwise feature requests would be closed/ignored/rejected.
  • As a maintainer of (Qubes-)Whonix I yet cannot foresee the project to gain enough resources to tackle controlling CPUID (which might require Xen patches) let alone making CPUs non-fingerprintable. So saying "This is up to (Qubes-)Whonix. Only happens if (Qubes-)Whonix does this." currently, unfortunately but realistically is similar to saying "Won't happen."

I am only kindly asking for a clarification. Not making any value judgement. Either position is of course very much reasonable given the limited project resources, difficulty to implement such features and so forth.

[andrewdavidwong]

Ultimately, it's @marmarek's call, but I'd say (A) and (B) are both partially accurate.

We're always open to good contributions, but we recognize how hard it is to get privacy right and how misguided it usually is when people think that they can attain strong privacy with one simple patch to a system that wasn't designed with privacy in mind. Often, it's because they just learned about a certain type of leak, and they assume that patching that one leak is all that's needed to achieve privacy, when in fact there are thousands of other leaks they haven't even learned about yet. This is why we generally defer to a holistic approach like Whonix in the spirit of (A).

Nonetheless, there may be cases in which Whonix requires something to be patched in Xen or Qubes in order to do its job, we are, of course, happy to consider and discuss what changes might be needed to support Whonix. In this sense, (B) might be stated too strongly. Of course, we always have to consider the trade-offs. Changes that improve privacy sometimes come at the cost of security and/or usability, so it would be up to the experts (e.g., you, Marek, and other devs) to work out what should be done.