<html>

  <head>

    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">

  </head>

  <body bgcolor="#282828" text="#FFCF22">

    <br>

    <div class="moz-cite-prefix">On 02/16/15 04:38, Joanna Rutkowska

      wrote:<br>

    </div>

    <blockquote cite="mid:54E1BAA9.4010701@invisiblethingslab.com"

      type="cite"><br>

      <pre wrap="">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 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.

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.

AFAIU, there are not personal identifying info returned by CPUID, but I

can see how this could be used as an additional fingerprinting vector.

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.

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

Thanks,

joanna.

</pre>

    </blockquote>

    <br>

    Getting back to parent thread's topic: The discovery of LAN IP

    address does not even require any intrusion/exploit into the

    system... it's really just a feature.<br>

    <br>

    But being on a '10.137' net is probably more identifying than

    having, say, an i5-3320M stepping 7 processor.<br>

    <br>

    So perhaps Qubes should have a configurable LAN address (like a

    regular router does) so that concerned users/admins can change it to

    something that is common but also works within their LAN

    environments.<br>

    <br>

    <br>

  </body>

</html>