On 07/07/2016 12:45 PM, Duncan Guthrie wrote:
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.
Qubes doesn't have good GPU support; It is a work in progress on many
fronts.
I mentioned that it could go in the direction of GPU virtualization or
better passthrough support, or both. In either case, there would still
be a protected primary graphics card that would at least render dom0 and
other trusted domains. But with the former, the primary graphics can
also safely process requests from untrusted domains. With the latter, a
secondary graphics card is still necessary (and indeed, that one becomes
untrusted at least during the untrusted session); this has little to do
with how the user controls the system, however.
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.
The wide audience is the kicker: The list of use cases get smaller only
when your target audience becomes (much) more narrow. People also like
Qubes because the promise of strong isolation suggests greater freedom
to try things and explore without nasty side-effects; I believe this is
a reason why Windows support was an early priority. But if the type of
supported hardware and apps becomes too narrow, the freedom seems more
like a mirage and the appeal of Qubes can fade.
What we define as the basics can come back to haunt us as a community or
a tech 'ecosystem'. VR is making new inroads as we speak, and calling
that 'games' is inaccurate to say the least; The applications are
wide-ranging. Even in the case of simple 3D drawing... how many would
want to go through college today without access to similar apps? Even if
needed for only part of a semester? What about 2D note-taking apps that
do heavy compositing and recognize handwriting and voice?
Teleconferencing is a really big one... so our 'terminal' is not even a
/good/ one. It goes on and on.
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.
OK... Although 3D printing was meant to /suggest/ innovative directions,
lets assume we rule out that use case for Qubes. So now almost every
savvy techie under the age of 35 becomes uninterested in Qubes because
3D printing is something most of them want to *explore*, even if they
never own a printer and use UPS stores instead... or if they never get
around to it. That kind of explicit deprivation (vs the deprivation
caused by 'it doesn't work /yet/') will be linked in their minds with a
very uneasy feeling about the unknown variety they are losing out on.
Think about how skewed that kind of demographic (for a piece of
technology) really is; Its unhealthy and starves the platform.
Qubes should be about simple and very strong isolation, wherein you can
deposit 'whatever' XYZ app and not have to fear for insidious malware,
surveillance, etc. Especially if I can make an untrusted Windows VM,
then why not?
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.
Yet this does suggest a kind of.... terminal.
In any case, I believe the concept of an OS somehow relegating graphics
overall to untrusted status to be a physical impossibility. Its not like
storage where the drives can be untrusted and handle encrypted (e.g.
unintelligible to the device) data with ease... encrypting a display
would be absurd.
Thanks for your correspondence,
D.
My pleasure,
Chris
--
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/9d2074d6-d2f7-1a99-53f8-1ec1c7a5c050%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
