On 11/13/2016 11:15 PM, Jean-Philippe Ouellet wrote:
On Sun, Nov 13, 2016 at 6:05 PM, Marek Marczykowski-Górecki
<[email protected]> 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/
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.
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/be2fe7ef-e073-69b6-0a04-e8f5fe295c0a%40gmx.com.
For more options, visit https://groups.google.com/d/optout.
