On 7 July 2016 16:53:35 BST, Chris Laprise <tas...@openmailbox.org> wrote: >On 07/07/2016 10:40 AM, Duncan Guthrie wrote: >> >> On 7 July 2016 03:28:48 BST, Chris Laprise <tas...@openmailbox.org> >wrote: >>> On 07/06/2016 09:42 PM, raahe...@gmail.com wrote: >>>> I'm not so adamant about wanting gpu passthrough on qubes, cause >>> imo, gaming online usually means all security is out the window. >Plus >>> I feel as though gpu is much bigger attack surface for side channel >>> attacks then net card. I could be wrong because I have no clue >about >>> low level stuff, but I feel it would somehow undermine purpose of >using >>> qubes. Maybe I'm wrong. >>> >>> I think this is wrong because many kinds of apps rely on GPUs now: >>> Media >>> decoding and creation, 3D design and printing (I would love to have >>> even >>> just SketchUp on Qubes!), and any other responsive 3D interface that >>> app >>> designers want to offer. This even includes web pages, >crypto-currency, >>> >>> and many scientific apps. GPUs are now general processing engines >that >>> embody MOST of a typical computer's processing power. >>> >>> This is not about games. >>> >> I think this is wrong. Most heavy computer users work in offices and >do word processing and spreadsheets, the 'average' casual use is >generally web browsing and light media consumption. >> Qubes works fine for using Libreoffice, web applications and social >media, and programming e.g. in Python. Graphics designers can use GIMP >or InkScape, or any of the Windows programs that they commonly use. >> It is true that you won't be able to use 3D applications like >SketchUp, but I do not think such tasks constitute most of the average >workload as you say. Perhaps they make up most of your workload, but I >don't think that you speak for everyone here. I have found Qubes works >for me, and people I know do similar tasks on their computers. >> >>> Furthermore, there is no getting around the fact that visual >rendering >>> is integral to security. The GPU can see any private info that you >can, >>> >>> and if compromised can take steps to trick users into sabotaging >their >>> own privacy and security. Like the CPU, the GPU must be accepted as >a >>> core component of trust, and protected as such... at least any GPU >that >>> >>> operates the admin and trusted domains. >>> >>> It is fortunate that we at least have a trend of integrated GPUs (in >>> APUs) where the GPU is manufactured into the same package as the >>> (implicitly) trusted CPU. For the time being, this is a boost to >Qubes' >>> >>> compatibility and security even if the GPUs are under-utilized. >>> >>> For Qubes to either 1) give up on GPU support, or 2) relegate them >to >>> untrusted status would be an _irretrievable_ error in judgment. It >>> would >>> make the OS a 21st century terminal application, because the lions >>> share >>> of the power expected by PC users would be missing (as it is >>> currently). >>> >>> Chris >>> >> I dispute this argument. Dropping "GPU support" (I am not sure where >you get this impression) is hardly going to make Qubes a terminal >application. You can use anything that uses 2D graphics, and can play >music and movies, and do word processing, and email, and software >development, and... The list goes on. Qubes is about security, and >allowing such high level access for the GPU is a terrible compromise. > >I am not proposing that domUs have direct access to graphics systems >operating in dom0. GPU access needs to be properly virtualized, and >thankfully some groundwork by Intel (and probably others) has been laid > >for it. Alternately, a specification for well-behaving discrete >graphics >could make graphics passthrough a realistic option for many people. > >Marek has already stated that any domU used for primary graphics (as >unrealistic as that may be, given the state of passthrough >compatibility) will be a trusted one, and that the purpose of such an >implementation would be to facilitate the use of Linux graphics drivers > >while the rest of the OS slims down and experiments with microkernel >admin and storage vms. > >The current state is, of course, one of trusting the GPU. That poses a >problem for those who want both discrete graphics and anti-tampering >(AEM) but otherwise? I don't see the compromise you mention. >
What are you suggesting then? You are criticising Qubes for not having good GPU support, but recognise that you can't have good security when GPU has access to hardware? I am sorry but I don't understand your point fully, and would appreciate it if you could elaborate further. What is your solution, do you want there to be virtualised domains for GPU? If I remember correctly, this is a feature being worked on. >Defining personal computing and what most people want as a list of >traditional activities--instead of using examples of innovative apps >and >the kind of directions app developers can go--is a mistake that leads >projects into an unbearable surfeit of unsupported corner cases. And >seriously-- if that's what it would come to then just develop a >convenient firmware verification and re-flashing system and run TAILS >on >the hardware; it would save considerable time and effort. > I wasn't really trying to "define personal computing", sorry if it appeared that way. What I am trying to say is that Qubes is aimed at a wide audience, and I think that Qubes adequately accomplishes the tasks I mentioned already, which are undoubtedly common tasks and use cases. It does the basics and more reasonably well while being reasonably secure. Certainly more can be done, though. I just think that some tasks that make heavy use of OpenGL are quite niche, like use of SketchUp, and at any rate on low-end systems (and some high-end systems) would be so slow as to be somewhat difficult, for example video games and use of software such as Blender. >An accurate view of use cases would hardly stop at office software and >playing music because almost everyone has make-or-break corner cases. >Teleconferencing and 3D printing, for example, are now SMB and home >user >activities that benefit from GPUs, which become more necessary due to >the extra CPU overhead of domain isolation. > Yes, this is true. However, 3D printers are fairly niche use cases (at least where I live); we don't have a 3D printer in every street for example. I am also pretty certain we can run teleconferencing software such as WebRTC (in Firefox Hello) and the various proprietary ones without much trouble. I'm willing to sacrifice some speed for security. You are right about Qubes benefiting from GPU, but I can't see how we can improve the performance without sacrificing security at the moment. At any rate GPU domains are being developed? I'm not entirely sure about this one. >As for suggesting server-based processing of large jobs to Qubes >users... I'm not even sure where to start with that one. > >Chris > I meant that statisticians and computer programmers often do tasks that require considerable computer power on an external server at their place of work. It is not a good example perhaps but I am saying that Qubes performance for intensive tasks (some of which might require GPU heavily) is not necessary a bottleneck in certain use cases, as such tasks are often accomplished on another computer anyway. It should have been clearer, so apologies on this one. Thanks for your correspondence, D. -- 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/84AE726D-1E1D-4CCB-91C9-3585AD3F02A3%40posteo.net. For more options, visit https://groups.google.com/d/optout.
