Re: [qubes-devel] [QWT] Update to qubes-windows-tools crosscompile project
On 12/23/20 12:59 PM, 'P. Hofmann' via qubes-devel wrote: > Hi, > > after setting up Qubes R4.1 Alpha on a new laptop I found that my old, > restored Windows Qubes would not work anymore with R4.1, the reason > being the updated qrexec protocol (from version 2 to 3). During my > research on the mailing list I stumbled upon the qwt-crossbuild project > by tabit-pro that addresses this and other issues. Unfortunately the > software did not compile right out-of-the box. I have made some minor > changes and created a github repo with the updated version: > Hi all, We are going to deprecate qwt-crossbuild in docker in favor of builds in mock as other our experimental packages [1]. There are other caveats related to dotnet running in wine, but I hope this method will be more convenient. It will be available in the next few days. Regards, Ivan Kardykov tabit.pro [1] https://github.com/tabit-pro/Qway-qubes-repo -- 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/663566be-2da1-497e-82e0-17035a8027fe%40tabit.pro. OpenPGP_signature Description: OpenPGP digital signature
Re: [qubes-devel] Re: GVT-g Discussion
On 2020-02-11 17:51, Marek Marczykowski-Górecki wrote: > On Thu, Feb 06, 2020 at 02:53:09PM +0300, Ivan Kardykov wrote: >> Greetings, > >> there is an update of our experimental GVT-g integration with Qubes. > >> Code was slightly improved to get rid of qemu. Vgpu init routine was >> moved to libxl and it works with stubdomain. > > >> https://github.com/tabit-pro/tabit-qubes-repo > > This is really interesting development! > Can you say something more about it? Specifically: > > 1. What a VM have access to really? Full GPU, some context? If a > context, how is it enforced? > > 2. What components are involved in GPU commands processing and how are > they isolated? > In theory [1] I see that each VM has access to frame and command buffers in system memory. The command buffer reused across VMs with smart shadowing and GVT framework validates graphics memory addresses before they used by the GPU. Access to the privileged resources (GPU Page Table Entries and I/O registers) is handled by xengt module, based on trap-and-emulation. Render context switching is used per vGPU. In practice, security audit is the matter of our further experiments. [1] https://www.usenix.org/system/files/conference/atc14/atc14-paper-tian.pdf > 3. Is it possible to enable it only for some VMs - in a way outside of VM > control? > We made several changes to the existing implementation to use it with qubes via qvm-features (video-model): - Patch to libxl creates vGPU instance via sysfs, during hvm domain execution. - Stubdomain part extends video model to prevent unnecessary initialization of emulated VGA. - Libvirt configuration adapted to parse xengt parameters. --- Regads, IK tabit.pro -- 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/a2c9b683-171f-6186-9a4c-4e0eca739802%40tabit.pro. signature.asc Description: OpenPGP digital signature
Re: [qubes-devel] Re: GVT-g Discussion
Greetings, there is an update of our experimental GVT-g integration with Qubes. Code was slightly improved to get rid of qemu. Vgpu init routine was moved to libxl and it works with stubdomain. https://github.com/tabit-pro/tabit-qubes-repo -- 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/3277ad93-e5c6-ccba-9007-639b1195775d%40tabit.pro. signature.asc Description: OpenPGP digital signature
Re: [qubes-devel] Re: GVT-g Discussion
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
Re: [qubes-devel] Re: GVT-g Discussion
On 2020-01-02 15:26, Kardykov Ivan wrote: > bump thread > > On Friday, November 22, 2019 at 5:02:14 AM UTC-5, Dylanger Daly wrote: > > Will the Qubes team consider enabling the use of GVT-g so we can > enjoy hardware accelerated graphics? > > After upgrading to DDR4 Memory I've noticed a significant increase > in performance, I assume this is because of the many, many memory > copies taking place, GVT-g should lighten the load. > > -- > 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 > <mailto:qubes-devel+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/qubes-devel/f608a18f-15e2-4ad1-94b3-da7ae8b1c553%40googlegroups.com > <https://groups.google.com/d/msgid/qubes-devel/f608a18f-15e2-4ad1-94b3-da7ae8b1c553%40googlegroups.com?utm_medium=email_source=footer>. Sorry for that bumping, but looks like my posts stuck 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. At now it works with some issues and limitations, most of them described in repository readme. We have tested it on Lenovo X1 gen5/gen6 and T480 laptops with KabyLake/KabyLake R chipsets. [1] https://github.com/tabit-pro/tabit-qubes-repo [2] https://github.com/intel/gvt-linux [3] https://github.com/intel/igvtg-qemu [4] https://github.com/xenserver/xen.pg.git Regards, Ivan Kardykov -- 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/9ffc85a2-9b21-b126-bfbb-831ebad2d7ed%40tabit.pro. signature.asc Description: OpenPGP digital signature
Re: [qubes-devel] QWT crossbuild project
> > Thanks for sharing! In fact I've already noticed it and got inspired a > little[3]. > On the other hand, we've tried that before and have bad experience with > building MinGW, especially for building drivers. I see you've also > noticed some stuff missing (libraries, headers, exception support, > inf2cat tool). Anyway, since you succeeded at building all of it, I > think it's worth a try. > Cross-compiling from Linux would be _much_ more convenient than building > on Windows, and hopefully will allow plugging QWT build into automated > build infrastructure. > > Creating a qubes-builder plugin for that isn't that hard. I have some > more or less working prototype already. Adopting sources to build with a > different compiler is some more work, but looks to involve mostly > rearranging header files (like, naming them with lowercase). Basically > what you've done in prep.sh, but by applying it properly to the source > code (using #ifdef __MINGW32__ when really necessary). > > After making it build at all, the next step would be to apply actual > improvements. And review/fix all the compiler warnings - there is quite > a lot of them, but given previous experience with mingw, one needs to > be careful - some may actually be bugs in mingw header files, not > necessary our code. > Glad to hear that our project experience could be useful in upstream. I understood described order of changes, and we are ready to implement some parts of them. We could step up to make clean patchset based on prep.sh with conditional changes to support MINGW. As I see easydozen got involved to issue discussion [3], so we could proceed to details in qubes-issues. > >> [1] https://github.com/tabit-pro/qwt-crossbuild >> [2] https://github.com/QubesOS/qubes-issues/issues/3418 > [3] https://github.com/QubesOS/qubes-issues/issues/5065 > > -- 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 post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/616da9d2-fa63-b6c2-ab13-6142388c2154%40tabit.pro. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
[qubes-devel] QWT crossbuild project
Hi, I want to share results of our (tabit-pro) work with Qubes project qwt-crossbuild [1]. It's an alternative qubes windows tools build environment that we are going to support for our local project. Main goals: -- get rid of closed source tooling in the build process -- provide build reproducibility -- catch and fix the most disturbing bugs -- extend QWT functionality (windows 10 support at least) At the moment IMO at least one PR (qga cpu usage, related issue [2]) could be made easily to the upstream. I'm not sure about others. For example, providing mingw support or changing installation process in the upstream would be too invasive and expensive. But we could try to schedule that work if anyone else is interested or make alternative community package (looks easier). Thanks for your job. [1] https://github.com/tabit-pro/qwt-crossbuild [2] https://github.com/QubesOS/qubes-issues/issues/3418 --- Ivan Kardykov -- 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 post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ca7ebb42-94c2-556e-5a01-e6048b3e2b27%40tabit.pro. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
