[Whonix-devel] Exposing AnonVM Users with Dom0 Hardware Fingerprint Leaks
whonixqubes at riseup.net
Tue Feb 17 11:55:37 CET 2015
On 2015-02-16 9:38 am, Joanna Rutkowska wrote:
> Xen has support for emulating CPUID for HVM guests -- take a look at
> config examples in:
I looked through the CPUID feature in this example file:
More general info on CPUID for others:
Some of the very low-level x86 implementation details of it are beyond
me currently, but, from what I can glean it looks like it is generally
the right type of thing, since it seems to be baked into the Xen Dom0
layer beyond the reach of the HVM's OS.
Would be looking for AnonVMs to simply not be able to know what CPU the
host machine is running on, by any means (barring covert channels or Xen
breakouts), but even including privilege-escalated malware in the VM.
> I haven't played with it, but see no reasons it should not work. I can
> imagine we introduce a prefs for VMs (say "generic_cpuid" settable via
> qvm-prefs) that would be resulting in additional config for cpuid
> emulation inserted in the config file for such VMs.
> We would need to
> agree on good-enough-for-everybody CPUID config and stick to it then.
> Again, this would be use-able for anon VMs mostly.
Yes. Sounds like a plan.
I'm guessing that this would *not* limit the speed of the CPU(s) that
the HVM is exposed to? Just changes the info/attributes of the AnonVM
domain's CPU (including reported MHz?)?
> However, this will not work for PV VMs, because the CPUID instruction
> not a privileged instruction, so malware in a PV VM can always execute
> this instruction (even if we hooked Xen interface for CPUID-like info
> the guest) without trapping into XEN in PV operation.
That's too bad for excluding paravirtualized VMs.
However, if there is no way to achieve a masked CPU with PVMs, then so
Given the general statistical environment of AnonVM users, I think
unique CPU info is too important of a de-anonymization vector to hold
onto PVMs for.
> AFAIU, there are not personal identifying info returned by CPUID, but I
> can see how this could be used as an additional fingerprinting vector.
For example, subdividing the cross-section of privacy/anonymity users by
the following attributes would no doubt be a privacy/anonymity killer
for individual human identities...
# of unique combined mixtures of the following attributes:
- # of Qubes Users
- # of Qubes + Tor AnonVM Users
- # of Qubes + Whonix AnonVM Users
- # of CPU Model Info
- # of CPU Microcode Version
...should be pretty easy to reveal individual people through their usage
of Qubes privacy/anonymity this way.
Although, AFAIK, other platforms are not totally immune from this. Some
just have a higher # of total users out in the world, but at their
technical expense of lacking strong security isolation to protect the
integrity of their privacy/anonymity systems.
> Thus, perhaps we should consider distributing Whonix workstation
> template as an HVM template instead of a PVM one? Fortunately we do
> templates support for HVMs, so this should be perfectly possible.
Assuming there is no feasible way to accomplish this objective with
PVMs, then implementing the Whonix-Workstation in a HVM template with
"generic_cpuid" sounds like the right move.
Another anonymity upshot of HVMs is their, by default, non-seamless
fixed single windowing. Even though the seamless desktop mode of the new
Qubes + Whonix platform is sexy and smooth to use, it does expose
another semi-unique host machine attribute to the AnonVMs, which is the
host's unique display resolution size and pixel depth (maybe some other
related stuff too?). Not as bad of an attribute as the host's unique CPU
info, but still would be best to make use of the fixed single windowing
for AnonVMs so this could be generic. Maybe both seamless and
non-seamless windowing options could be offered for Whonix-Workstation
HVM template, since some people hate non-seamless.
> Let me also point out the already discussed-multiple-times topic of
> potential covert channels between cooperative VMs, which might also be
> potentially exploited in some scenarios to fingerprint user
> That is more difficult to address on PC architecture though, but some
> work on Xen-level is nevertheless very welcome (see #817).
Yes. I have read through some of your stuff on covert channels in the
past, including in the original Qubes architecture spec doc.
Just read through the thread linked in Qubes ticket #817 from 2014. Good
More information about the Whonix-devel