Re: [qubes-users] GPU Passthrough Status - (Purely a meta-discussion, no specifics)
On Sunday, 17 December 2017 12:16:04 UTC, Tom Zander wrote: > On Saturday, 16 December 2017 03:25:46 CET Yuraeitha wrote: > > Initially, this is all the reasons I can think of for wanting V-GPU. > ... > > - Extending a single Qubes machine around the house or company, using > > multiple of screens, keyboards/mouses or other thinkable means. > > This sounds inherently unsafe. > Not sure what your usecase is, but there has to be a better way than > allowing a multitude of foreign, not-directly-connected hardware from > accessing various very security sensitive channels. > > ... > > - Cryptocoin miners who wish to utilize a single machine > > for all round purposes. > > To build a proper crypto-mining rig based on GPUs, you would not run an OS > on the machine. It literally drains money out of your system to use it on > the same hardware as you main desktop. > If you install 8 GPUs on a mainboard, you have to realize that the mainboard > ends up costing a fraction of the total. > Reusing it for non-mining purposes (while mining) just doesn't make any > sense. Both from an economics as well as a security point of view. I think it makes sense it you are on a budget. But you do not need GPU path-through, you only need CUDA interface, so I believe it is already feasible today. Use the integrated GPU for Dom0 and all your work VMs. Have a MiningVM with all the other GPU attached to it. However ,you probably want a kvm switch to distance yourself from your new radiator and noise generator. > > -- > Tom Zander > Blog: https://zander.github.io > Vlog: https://vimeo.com/channels/tomscryptochannel -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/13948b3c-f21f-45ae-ae87-20593c6d424e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] GPU Passthrough Status - (Purely a meta-discussion, no specifics)
On Saturday, 16 December 2017 03:25:46 CET Yuraeitha wrote: > Initially, this is all the reasons I can think of for wanting V-GPU. ... > - Extending a single Qubes machine around the house or company, using > multiple of screens, keyboards/mouses or other thinkable means. This sounds inherently unsafe. Not sure what your usecase is, but there has to be a better way than allowing a multitude of foreign, not-directly-connected hardware from accessing various very security sensitive channels. ... > - Cryptocoin miners who wish to utilize a single machine > for all round purposes. To build a proper crypto-mining rig based on GPUs, you would not run an OS on the machine. It literally drains money out of your system to use it on the same hardware as you main desktop. If you install 8 GPUs on a mainboard, you have to realize that the mainboard ends up costing a fraction of the total. Reusing it for non-mining purposes (while mining) just doesn't make any sense. Both from an economics as well as a security point of view. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8533554.PhlilUoQuC%40cherry. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] GPU Passthrough Status - (Purely a meta-discussion, no specifics)
On Sunday, 17 December 2017 11:59:26 CET Yuraeitha wrote: > f, but from what I understand, complex software is hard to make secure, > compared to well-made hardware minimizing use of software. If Qubes > hypothetically were to adopt these, would the hardware approach be more > secure here? The question isn't really about software vs hardware. The overall design and concept is what is more important. The actual approach of how to do this makes or breaks the security mode. >From that approach follows what parts are required to be in hardware (to still be fast and secure). I claim no expertise in the domain you address in this thread, so apologies for the generic answer. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1828191.tAHdXYOLUq%40cherry. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] GPU Passthrough Status - (Purely a meta-discussion, no specifics)
On Saturday, December 16, 2017 at 4:47:24 PM UTC+1, awokd wrote: > On Sat, December 16, 2017 2:25 am, Yuraeitha wrote: > > Aight, so the idea of this thread, is to get an overview of where we > > stand, that is, how far are we away from archiving GPU Passthrough on > > Qubes. > > If you look at how the "competition" is approaching it, you need GPU > hardware capable of virtualization such as Nvidia Grid, Radeon Sky(?), > Intel GVT-g and hypervisor support. > > https://www.nvidia.com/object/grid-technology.html > https://www.amd.com/en-us/innovations/software-technologies/sky > https://01.org/igvt-g > https://code.vmware.com/article-detail/-/asset_publisher/8n011DnrSCHt/content/vsga-datasheet > https://docs.citrix.com/content/dam/docs/en-us/xenserver/xenserver-7-0/downloads/xenserver-7-0-configuring-graphics.pdf > > Not something I've ever played with, but it seems kind of like IOMMU to > me. You could write a software layer to provide slow virtualized GPUs, or > use hardware for faster ones. > > Of these, it seems like Intel's approach is the most open source friendly. > XenGT has working code. No idea how hard it would be to integrate with > Qubes, though. > That's a very interesting perspective, to bring in the market movements and other open source developments into the discussion as well, possibly detecting spots that might work together with Qubes. The competition also seems to be getting more fierce as virtual augmentation and reality becomes bigger? That's a very good idea for topic discussion too, I agree. It's interesting questions you set in motion, like for example to ponder over how far these developments can be be put together with Qubes with our current or emerging means of tomorrow. Between software or hardware controlled IOMMU graphics, maybe the question for Qubes is which one of them is more secure though? I'm not a code developer my self, but from what I understand, complex software is hard to make secure, compared to well-made hardware minimizing use of software. If Qubes hypothetically were to adopt these, would the hardware approach be more secure here? Or maybe one can even use software controlled IOMMU in a less secure Stub-domain, for less important things as well? Kind of like a Qubes opt-in feature? I wonder how feasible this would be though, but it sounds really attractive to have user-choices like these. I haven't read through all the links and their interconnected topics yet, but plan to do that over the next couple of days as I have more time. The ones I read were quite interesting to read already. > > I must be tired, I initially wrote 'qubestions' instead of 'questions' > > here... aight, so possible questions for the discussion. > > I like it! Let's rename the FAQ to Frequently Asked Qubestions. huehue, mistakes when tired (or even when high) can lead to some interesting places sometimes :-) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/534e830a-cbed-4d37-99f8-9c9d47383d77%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] GPU Passthrough Status - (Purely a meta-discussion, no specifics)
On Sat, December 16, 2017 2:25 am, Yuraeitha wrote: > Aight, so the idea of this thread, is to get an overview of where we > stand, that is, how far are we away from archiving GPU Passthrough on > Qubes. If you look at how the "competition" is approaching it, you need GPU hardware capable of virtualization such as Nvidia Grid, Radeon Sky(?), Intel GVT-g and hypervisor support. https://www.nvidia.com/object/grid-technology.html https://www.amd.com/en-us/innovations/software-technologies/sky https://01.org/igvt-g https://code.vmware.com/article-detail/-/asset_publisher/8n011DnrSCHt/content/vsga-datasheet https://docs.citrix.com/content/dam/docs/en-us/xenserver/xenserver-7-0/downloads/xenserver-7-0-configuring-graphics.pdf Not something I've ever played with, but it seems kind of like IOMMU to me. You could write a software layer to provide slow virtualized GPUs, or use hardware for faster ones. Of these, it seems like Intel's approach is the most open source friendly. XenGT has working code. No idea how hard it would be to integrate with Qubes, though. > I must be tired, I initially wrote 'qubestions' instead of 'questions' > here... aight, so possible questions for the discussion. I like it! Let's rename the FAQ to Frequently Asked Qubestions. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/61a84e9c7dc6a5d9303fdd39f3c25ca9.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] GPU Passthrough Status - (Purely a meta-discussion, no specifics)
Aight, so the idea of this thread, is to get an overview of where we stand, that is, how far are we away from archiving GPU Passthrough on Qubes. The underlying reason it's currently not working, appears to be because of its current state a virtual GPU for a specific VM, would require direct access to dom0. This is deemed a serious security threat breaking a central pillar of what Qubes is all about, attempting to isolate dom0 as far as possibly possible. Therefore, from what I can gather, what we need is virtual GPU operating from an underlying DomU stub-domain, preferably, one separated from another DomU stub-domain, which holds the important and critical VM data and user operations. Thereby it's not only about single virtualization anymore, but also about group segmenting and isolating entire virtual stub-domains. That means, one group of VM's is isolated from another group of VM's. Please correct me if I'm wrong here, it's great for the discussion to have the most accurate information. Here is a scenario that stresses the above, https://groups.google.com/forum/#!topic/qubes-users/cmPRMOkxkdA Managing to make GPU passthrough work, but only by passing it directly to Xen, instead of Libvirt, which in turn, exposes dom0. Initially, this is all the reasons I can think of for wanting V-GPU. - Heavy graphic designer job or hobby (movies, animations, etc.). - Running Qubes on many screens at desk. - Extending a single Qubes machine around the house or company, using multiple of screens, keyboards/mouses or other thinkable means. - Gamers who take security and privacy seriously (there is surprisingly many of them out there). - Cryptocoin miners who wish to utilize a single machine for all round purposes. - Using a qube as a streaming TV, and want good graphics for the specific TV-VM. For example 4k or even 8k+ or more on multiple tied screens. Some of these are exotic and probably not many around use them, however, others are quite common. Whichever the case, it's all scenarios with a common problem. The point here, is to underpin the possible use-cases. I must be tired, I initially wrote 'qubestions' instead of 'questions' here... aight, so possible questions for the discussion. - What would it take for Qubes to obtain stubdomains in a feasible means to allow safe GPU Passthrough? - Are there other problems that needs solving too? If so, which ones? - What is the grand big picture status between the above two questions? - Are there currently any plans for any of these required implementations? For example Qubes stub-domains in Qubes 4.1? Qubes 5? or are they still unplanned? If planned, or in part planned, like only halfway there, then, what are these plans? Please elaborate. - Other possible questions you can think of. I'm sure there are aspects I did not think of, but that's fine, after all, this is a discussion. This initial post is just to kick it off. The purpose is to combine information that a few selected individuals might be sitting on, with the many users who do not know about the current state. Thereby, building community awareness of the current situation. Whatever you got to say, or ask, about GPU Passthrough, this thread can be used for that! The only limitation, is that it is a discussion, and not a place to ask how to get your own specific case of GPU Passthrough to work. It's a general, meta discussion. What is your thoughts on the matter? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2dad5415-fd4b-42f7-b6cb-ad0094cfca07%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
