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. 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/430e381e-7118-5660-38b5-9db65399b02d%40gmail.com.
signature.asc
Description: OpenPGP digital signature
