[Whonix-devel] Exposing AnonVM Users with Dom0 Hardware Fingerprint Leaks

Tue Feb 17 11:55:37 CET 2015

Hi Joanna,

On 2015-02-16 9:38 am, Joanna Rutkowska wrote:
> 
> Xen has support for emulating CPUID for HVM guests -- take a look at 
> the
> config examples in:
> 
> xen-4.1.6.1/tools/examples/xmexample.hvm-stubdom

I looked through the CPUID feature in this example file:

- 
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob_plain;f=tools/examples/xmexample.hvm-stubdom;hb=stable-4.1

More general info on CPUID for others:
- https://en.wikipedia.org/wiki/CPUID

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.

Sounds good.

> 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 
> is
> 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 
> to
> 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 
be it.

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.

Right.

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 
> have
> 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 
> environment.
> 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 
stuff.

WhonixQubes