See:
opened 12:21AM - 21 Aug 15 UTC
closed 11:45PM - 17 Oct 18 UTC
C: core
C: Xen
privacy
R: declined
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.
as time goes on i’m learning qubes isn’t as private and secure as i originally belived
while this sepsific issue is less important to me personally (since i care more about security then privacy…) you’d think that by principal the hardware id should be hidden from vm’s by default…
and while yes it is hard to believe any entity less powerfull then maybe a full blowen government would be able to use such a “meaningless” piece of information
think of the journalists using qubes and tyranical gov…
-> Eliminating ever deeper "cookies" -> identifying marks ->
Any media with JavaScript can potentially fingerprint the CPU of a device and nothing works with LibreJS although it is a good concept. Java is a significant privacy risk. Apparently, hardware information can even be obtained past virtualizers. Is anyone working on developing obfuscation for physical, fabrication process specific frequency identifiers of CPU and other hardware? Benchmarking resistance? Can anyone explain how the…
I think this was done, but not sure that helps.
Intel:
AMD:
I don’t know if this can be used to disable CPUID.
And even if possible, this is not a reliable approach. These vulnerabilities are considered security issues by hardware and firmware vendors. The only option would be to buy vulnerable hardware (to avoid buying hardware that is currently not supporting to run unauthorized microcode) and to abstain from installing BIOS updates (which would prevent unauthorized microcode). Not installing BIOS updates can lead to other security issues.
This is a far to messy situation for anyone to start maintaining a project that disables CPUID through unauthorized microcode.
2 Likes