On 2020-01-02 18:34, Demi M. Obenour wrote: > On 2020-01-02 15:33, Kardykov Ivan wrote: >> Sorry for that bumping, but looks like my posts from work domain (tabit.pro) >> stucked at moderate or >> spam checks.. So my message was about GVT-g. >> >> We have some success with adaptation Intel gtv-g technology to Qubes OS. >> At now it is rather proof of concept state, but it probably could help >> to test guivm features and discuss of applicability in practice. >> >> In this [1] repository we placed specs and patches to build core Qubes >> components with ability to run and work with GPU accelerated VM. We >> oriented to Fedora 29 dom0 and Xen 4.12 versions with plans of 4.1 >> compatibility. Now it is up to Fedora 31 and Xen 4.13 and we will get to >> this versions in some time. >> >> We made and adapted patches to xen, kernel, libvirt, qemu to dom0 and >> xorg dummy driver to guest environment. Our work mostly based on Intel >> [2][3] and XenServer [4] public repositories. >> >> The most controversial question is probably running qemu without any >> restrictions, but there are several ways to improve it. > > As Marek has stated before, this is a non-starter. QEMU is not > considered trusted. Xen’s attack surface is already too high. >
As I see it, useful results could be with testing it to get more about advantages and finding ways to minimize risks. May be smth with this [1] movements are compatible with gvt-g. [1] https://wiki.xenproject.org/wiki/Linux_stub_domains > The approach I would like to see is a paravirtualized approach > similar to Genode’s: a small (<10K SLOC), auditable (ideally > formally verified) driver running in dom0 and/or its own domain that > communicates with a paravirtualized driver in the VMs. Any needed > emulation is done in the stubdomain. This is likely to be difficult > for many reasons, but is the only way that I see can hardware > accelerated graphics being secure enough for Qubes with commodity > hardware. If you are willing to pay literally thousands of dollars > for server-grade GPUs, then SR-IOV and friends become options, which > make secure hardware acceleration much easier. However, those are > far too expensive for virtually all Qubes users. In particular, > they are far more expensive than just buying another computer for > graphics-intensive activities. > > The main activities I know of that need hardware-accelerated graphics, > and which a Qubes user is likely to want to partake in, are gaming > and GPGPU. Video games, in particular, should be considered completely > untrusted, and so need to be walled off as tightly as possible. > > Sincerely, > > Demi > -- 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 qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/8dce113c-6afa-3181-9f1c-7eb140b0b725%40tabit.pro.
signature.asc
Description: OpenPGP digital signature
