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.

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.

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.

As for suggesting server-based processing of large jobs to Qubes users... I'm not even sure where to start with that one.

Chris


Plus as a gamer myself,  I always want the most fps the machine can
dish,  and that's definitely not by running games in a vm.
I have a separate machine for sensitive and daily tasks running
qubes.  Most people use consoles for gaming now anyways.  Hardware
industry has been dying for a decade and I never had any reason or
thought I would ever build a custom pc again,  until qubes!  :)
If you are doing something really heavy like statistical work you often would 
use a dedicated server for this. As far as I know connecting to such servers 
would be possible using Qubes. At any rate you could always use Qubes for 
personal use and then have a dedicated work computer for stats, 3D development, 
etc.

These are just my own observations.
Hope it helps,
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/5d7a7797-2ec9-0df0-aaf0-db14b7294a4e%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Reply via email to