The Current State Of GPU Utilization?

[Trioxin]

As a developer, I see Qubes as an amazing opportunity to develop and test my software on multiple operating systems from a central secure location. I develop marketing software, games, and machine learning algorithms. For a lot of that, I need to utilize my GPU (A Titan X Pascal). I haven't installed Qubes yet but I was doing research and all I could find was a thread here that started in 2014 and had one post from 2015.

As a user, I must say that if my OS can't utilize my GPU in my OS, it's not an OS I can use for day to day operations. I read about the security concerns and it's no more a concern that any other device you plug into your computer. The GPU isn't some gaping security hole. Today's motherboards and various other components have firmware scattered about your system. The GPU is no more insecure than them and it's a critical component of any computer.

What's the current capability for GPU utilization? Would I be able to activate my GPU for one of the installs so I can run my machine learning code against it or run a 3D environment? The GPU should also be powering the UI of the OS. The point of my post here isn't to provoke, rather to point out the absurdity of what I suspect might still be the neglect of attention to GPU utilization for this OS. I'd really love to use Qubes and so would so many other people but if they come along and realize their GPU means nothing here, well...

[Trioxin]

[Aktariel]

What's the current capability for GPU utilization? Would I be able to activate my GPU for one of the installs so I can run my machine learning code against it or run a 3D environment? The GPU should also be powering the UI of the OS. The point of my post here isn't to provoke, rather to point out the absurdity of what I suspect might still be the neglect of attention to GPU utilization for this OS. I'd really love to use Qubes and so would so many other people but if they come along and realize their GPU means nothing here, well...

It's never been officially supported, and last I saw there was a heck of a lot of trouble getting it to work properly (requiring hacking around with libvirt configs at best). I should have hardware to test shortly; I can let you know how it goes (planning on trying to pass through the dedicated card to a Windows VM). 

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, Oct 22, 2016 at 10:50:53PM -0700, Trioxin wrote:
> As a developer, I see Qubes as an amazing opportunity to develop and test
> my software on multiple operating systems from a central secure location. I
> develop marketing software, games, and machine learning algorithms. For a
> lot of that, I need to utilize my GPU (A Titan X Pascal). I haven't
> installed Qubes yet but I was doing research and all I could find was a
> thread here that started in 2014 and had one post from 2015.
>
> As a user, I must say that if my OS can't utilize my GPU in my OS, it's not
> an OS I can use for day to day operations. I read about the security
> concerns and it's no more a concern that any other device you plug into
> your computer. The GPU isn't some gaping security hole. Today's
> motherboards and various other components have firmware scattered about
> your system. The GPU is no more insecure than them and it's a critical
> component of any computer.

The GPU _is_ somehow special - not only because of its complexity, but
mostly because of the data it handle. If someone control the GPU, he/she
control what you see on the screen and can capture it (break privacy),
or replace it (break integrity). Of course in theory you could expose
only "subset" of GPU to particular VM (for example allow access only to
some predefined surface), but in practice (because of its complexity) it
is hard to do securely. There is XenGT project from Intel which tries to do
something like this, but it isn't fully functional yet.

The above mostly applies to shared GPU. If you have separate GPU and
want to assign it to just one selected VM, it should be possible in
theory right now. In practice - you've found already how it works...
This should be doable, but it isn't our top priority right now - we have
a lot of higher priority tasks...

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYKPGoAAoJENuP0xzK19csPi0H+wZtTpKaQvewkcsPOm6Sluy4
60Pl9J2HRWISHJ9sI+EFQWSX1wxNW4rW4miryZwJgVHI++vyd8c234EbWtIm0DKc
JsF8qXgi1mGkNEObyFjdAF0c7CVRwPuxapv13WVZ2MuWnJ0YVZn15ev4dV4IgdrF
FTkkuQcYj2i8kwqmRO4QYQqx4WDS/hwbXGdwVG+Klu6ICNW/Ieoq2DqMnhBT/Qk9
SfNnnuU+l/P3Hh6YZf2uJfqZKb2IN7kQIAofHAcQ5sRbc5DVOkovrooJangVQWiP
uDLFlsBw3kP61Cuhed4vgQtKOCI9LVKMbozneYPo90lWX2drNao1Wg69NFFMzHw=
=J2NS
-----END PGP SIGNATURE-----

[Aktariel]

Sort of a shame, but I understand the issues and why it's problematic, and also that support for it is low on the priority list. A lot of higher end laptops have two GPUs these days, and for those of us with lower threat levels, gaming inside a Windows VM is still attractive. It can be disabled in BIOS usually to save power, but then it's just sitting there doing...not much.

[Jean-Philippe Ouellet]

On Sun, Nov 13, 2016 at 6:05 PM, Marek Marczykowski-Górecki
<marm...@invisiblethingslab.com> wrote:
> Of course in theory you could expose
> only "subset" of GPU to particular VM (for example allow access only to
> some predefined surface), but in practice (because of its complexity) it
> is hard to do securely. There is XenGT project from Intel which tries to do
> something like this, but it isn't fully functional yet.

XenGT is a very scary amount of code which directly exposes very large
and complex (trusted!) code paths to guests.

To copy from an email I sent privately earlier:

The effective TCB increase due to XenGT isn't just that (large) hypervisor
patch[1], it's also the kernel component in dom0[2], which is quite
substantial and *WAYYY* more of an attack surface than the qubes-gui
protocol[3]. That's a significant increase in complexity, and I am not
aware of any auditing of those patches outside whatever internal
code-review intel may presumably do.

IMO, using only the already-trusted code paths for general
PCI-pass-through of a whole GPU would be safer (assuming the probability
of your adversary compromising and pivoting from your GPU's firmware
is lower than being able to find a hole in XenGT).

Even if XenGT works great, I would not like to see it adopted in Qubes
unless it is throughout audited (which I am not qualified to do to a
level where I would be comfortable trusting it, and it is not a
priority for those who can). The Qubes GUI passing protocol today
works very well for the majority of use cases, and was designed very
much with security in mind.

[1]: https://github.com/01org/XenGT-Preview-xen/blob/master/xen-vgt.patch
[2]: https://github.com/01org/XenGT-Preview-kernel/commit/54c0df4432bd365de08203d866fed89fcc9aa267
[3]: https://www.qubes-os.org/doc/gui/

[Jean-Philippe Ouellet]

On Sun, Nov 13, 2016 at 11:15 PM, Jean-Philippe Ouellet <j...@vt.edu> wrote:
> Even if XenGT works great, I would not like to see it adopted in Qubes

> unless it is throughout audited (which...

Although, I could see a legitimate argument for the other side:

One might argue that the set of people whose daily work truly requires
3d acceleration would be better served by using Qubes with holes in it
due to XenGT than whatever other monolithic system they use today, and
as long as it is off by default and comes with appropriately scary
warning labels attached, including it would be a net positive.

[Tai...@gmx.com]

I suppose an idea is to modify coreboot/etc for some level of IOMMU
assurance where certain lists of devices are designated as permanent
pass through, assumed hostile and thus never allowed to communicate with
the VMM/host OS.

If it is only done in os kernel/software then lets say one day you have
to boot a rescue cd that doesn't have those security features - what
then? - which is why it should be built in to the firmware.

One could also replace the GPU firmware chip with one that can't be
flashed internally, thus a reset would cover security.