Possible privacy concerns with Qubes 4 and the transition away from paravirtualization?

[rigged...@gmail.com]

I've been reading about Qubes OS for the past few days, and I came across the blog post below, detailing the switch from paravirtualization to hardware-enforced memory virtualization in Qubes 4. As I understand, the switch is intended to improve security (and avoids the overhead added by conventional hardware-assisted virtualization by using SLAT).

https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/

However, I noticed a few people voicing privacy concerns regarding the switch from paravirtualization to hardware-enforced memory virtualization.

Here's one such comment, taken from an r/privacy Reddit thread.

"Qubes v.4 does concern me though. I am NOT an expert here so I dont want to spread bad info but: Qubes 4 plans to ditch paravirtualization in favor of hardware-enforced memory virtualization (which I will call HEMV though I dont think it has an official acronym). This is good from a security standpoint- paravirtualization is vulnerable to code exploits (2 have happened to Xen, though never in the wild, KVM/Virtualbox/VMware have all had exploits), while HEMV is not. However, HEMV makes the profiling of hardware easier to accomplish. Given the recent spat of articles that talk about hardware profiling being used as a means to profile and track users, you can understand the basis for my concern- paravirtualization makes hardware profiling impossible unless an exploit is found to defeat it."

Does this hold any water? Does the switch from paravirtualization to HVM/SLAT degrade privacy by allowing easier hardware fingerprinting?

Sorry if this question has been asked and answered before; I searched around for a while, and found none. Also, feel free to correct me on anything I got wrong. Thanks! :)

[Jean-Philippe Ouellet]

On Sun, Nov 19, 2017 at 7:17 PM, <rigged...@gmail.com> wrote:
> Here's one such comment, taken from an r/privacy Reddit thread.
>

> "[...]paravirtualization makes hardware profiling impossible unless an exploit is found to defeat it."

That statement is demonstrably false. For example, we don't filter
CPUID vendor IDs in either mode.

https://xkcd.com/386/

Cheers,
Jean-Philippe

[rigged...@gmail.com]

Cheers, Jean-Philippe! Thanks for the reply.

Would you be able to point me in the direction of any unique privacy-specific functions Qubes OS allows me to take advantage of (other than obvious stuff like Whonix)? Is there anything of that sort?

Thanks again!

[Alex]

> Cheers, Jean-Philippe! Thanks for the reply.
>
> Would you be able to point me in the direction of any unique privacy-specific functions Qubes OS allows me to take advantage of (other than obvious stuff like Whonix)? Is there anything of that sort?
>
> Thanks again!
>

Qubes OS's main focus is security, not privacy: since Qubes OS is an
operating system it is, architecturally, infrastructure, and
infrastructure does not directly provide privacy.

Privacy is a feature of behaviour and services, not infrastructure;
that's why any User can keep a privacy-oriented behaviour (e.g. by using
pseudonyms, wearing masks, or even taking part in a theatrical play: if
actors are not named, you only know the character) and/or use privacy
friendly services (e.g. that don't keep logs or don't force specific
types of identities, or that actively mix network traffic to avoid
correlation).

In this context you should understand that Qubes OS or Whonix are
neither services nor behaviours, and that's why you can use Whonix
without any privacy (just log in to Facebook and post as yourself, or
record a vlog post on Youtube).

Infrastructure, like Whonix and Qubes, may ease privacy by configuring
software (e.g. to run over TOR) or preventing the circumvention of
behaviours (e.g. avoid tracking network traffic), but they don't provide
privacy by themselves.

Same goes for anonymity, which (imho, but that's a pretty big
digression) is a specific type of privacy.

Please look at the switch away from paravirtualization from a technical
point of view, and only when the infrastructural implications are clear
then you can take into account the impact (if any) for privacy-enabling
behaviours and services.

--
Alex

[Chris Laprise]

One thing that is a bit similar to Whonix in terms of privacy is the VPN
clients can be configured on Qubes. With a dedicated VPN VM, leaks
around the VPN tunnel can be prevented much better than on a regular OS.
There is a VPN guide in the Qubes docs site.

Overall, what makes Qubes great for privacy is that privacy is best
implemented on top of strong security.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Tai...@gmx.com]

On 11/19/2017 07:17 PM, rigged...@gmail.com wrote:

Does this hold any water? Does the switch from paravirtualization to HVM/SLAT degrade privacy by allowing easier hardware fingerprinting?

It holds no water.

There is no such thing as "hardware fingerprinting" - what is usually done for DRM or w/e is simply reading the model names and serial numbers of hardware installed - nothing truly "magic".

You can easily change what is displayed in lscpu for example no matter if you are using HVM or software virt.
In any virt system the graphics device name isn't displayed in the VM nor your total amount of RAM or serial numbers of drives.

Self proclaimed experts on reddit who mention something provocative but provide no technical information almost always have no idea what they are talking about.

[Tai...@gmx.com]

On 11/20/2017 04:36 AM, Jean-Philippe Ouellet wrote:

> That statement is demonstrably false. For example, we don't filter
> CPUID vendor IDs in either mode.

How come?
I didn't know you were a dev :0

[Jean-Philippe Ouellet]

On Mon, Nov 20, 2017 at 5:59 PM, Tai...@gmx.com <Tai...@gmx.com> wrote:
> On 11/19/2017 07:17 PM, rigged...@gmail.com wrote:
>
> Does this hold any water? Does the switch from paravirtualization to
> HVM/SLAT degrade privacy by allowing easier hardware fingerprinting?
>
> It holds no water.
>
> There is no such thing as "hardware fingerprinting"

Then what do you call checking e.g. clock drift, disk bandwidth, etc.?

[Jean-Philippe Ouellet]

On Mon, Nov 20, 2017 at 6:04 PM, Tai...@gmx.com <Tai...@gmx.com> wrote:
> On 11/20/2017 04:36 AM, Jean-Philippe Ouellet wrote:
>
>> That statement is demonstrably false. For example, we don't filter
>> CPUID vendor IDs in either mode.
>
> How come?

See discussion at https://github.com/QubesOS/qubes-issues/issues/1142

> I didn't know you were a dev :0

Eh, I'm not really, I just spend some free time working on things that
are either interesting or that bother me :)

[Tai...@gmx.com]

On 11/20/2017 06:08 PM, Jean-Philippe Ouellet wrote:

On Mon, Nov 20, 2017 at 5:59 PM, Tai...@gmx.com <Tai...@gmx.com> wrote:

On 11/19/2017 07:17 PM, rigged...@gmail.com wrote:

Does this hold any water? Does the switch from paravirtualization to
HVM/SLAT degrade privacy by allowing easier hardware fingerprinting?

It holds no water.

There is no such thing as "hardware fingerprinting"

Then what do you call checking e.g. clock drift, disk bandwidth, etc.?

I consider hardware fingerprinting to be something permanent, those are not and are limited to finding out that two VM's are on the same PC.

[Tai...@gmx.com]

On 11/20/2017 06:10 PM, Jean-Philippe Ouellet wrote:

On Mon, Nov 20, 2017 at 6:04 PM, Tai...@gmx.com <Tai...@gmx.com> wrote:

On 11/20/2017 04:36 AM, Jean-Philippe Ouellet wrote:

That statement is demonstrably false. For example, we don't filter
CPUID vendor IDs in either mode.

How come?

See discussion at https://github.com/QubesOS/qubes-issues/issues/1142

That is pretty silly reasoning from the "closedwontfix" camp.

Saying CPU model 5xxx is much different than saying CPU model 5412, libvirt already supports that so I see no reason not to.

[qub...@leo.gaspard.ninja]

Well, the clock drift in an intrinsic feature of your processor clock,
disk bandwidth of your disks, etc.

This kind of hardware fingerprinting is something permanent. And
preventing it requires willfully slow things down, things I don't expect
a general-purpose OS like Qubes to do.

Actually this kind of hardware fingerprinting can even be done in
javascript, thanks to all the optimizations performed. Basically, the
faster (hence closer to the metal) the attacking program runs, the
better it can fingerprint your hardware, usually.

HTH,
Leo

PS: Yes, I'm making things look simpler than they are, I know, but it
has to fit in an email.