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.

[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.

[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?

[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 ?

[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]

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

[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/

[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]

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?

[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?