Question about windows HVM

17,897 views
Skip to first unread message

bradbury9

unread,
Jan 23, 2013, 7:51:08 AM1/23/13
to qubes...@googlegroups.com
Hi,

I want to give qubes a try but actually dont have any decent hardware to try it on. On another side I am planning to get a gaming desktop computer so I was thinking maybe I could combine both needs (aka, gaming qubes). There go my questions...

- Could be possible to get a windows HVM with DirectX (9.0C) and big amount of RAM (minimum 6 GB)? If not, does default qubes installation allow dual boot?
- Any plans on allowing HVM get fullscreen or is there any security risk?
- Is it posible to get a templateVM (probably ubuntu or mint) with OpenGL?

BTW, you guys are doing a great job providing security to regular users.

Joanna Rutkowska

unread,
Jan 23, 2013, 8:20:32 AM1/23/13
to qubes...@googlegroups.com, bradbury9
At this moment (Release 2) there are no plans to add DirectX/OpenGL/GPU
support for AppVMs. However, given the fact you're building a custom
desktop, you might try adding another GPU card and try to pass it
through one of the HVMs (I guess qvm-pci should do the work as with any
other PCIe device, although I never tried that). So you will want to
pass your powerful GPU to the HVM, and leave some old GPU at dom0 for
the standard Qubes desktop.

Do let us know if that worked or not!

joanna.

signature.asc

Marek Marczykowski

unread,
Jan 23, 2013, 8:23:52 AM1/23/13
to qubes...@googlegroups.com, Joanna Rutkowska, bradbury9
As a follback option you can setup dual boot environment (manually, but
doable). Don't forget about Anti Evil Maid to protect /boot against the other
system.

--
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab

signature.asc

bradbury9

unread,
Jan 23, 2013, 11:41:58 AM1/23/13
to qubes...@googlegroups.com
Joanna, Marek, thanks for the info, greatly appreciated.

I will try Joanna advice and, if failed, Marek's one. Will have two gaming HVM

One for a fedora17 (or ubuntu) HVM. Steam has Fedora 17 and ubuntu packages/repo (with debian or mint some tweaks must be done to the deb package, wrong dependencies on the Steam deb package) so with the correct packages should work fine.
The other one for HVM (windows) using qvm-pci.

My plan is to get the hardware in about a couple of months, will let you know if works fine, emailing to update HCL.

Many games try to get fullscreen, would it cause problems with the HVM?

Marek Marczykowski

unread,
Jan 23, 2013, 11:49:27 AM1/23/13
to qubes...@googlegroups.com, bradbury9
On 23.01.2013 17:41, bradbury9 wrote:
> Joanna, Marek, thanks for the info, greatly appreciated.
>
> I will try Joanna advice and, if failed, Marek's one. Will have two gaming
> HVM
>
> One for a fedora17 (or ubuntu) HVM. Steam has Fedora 17 and ubuntu
> packages/repo (with debian or mint some tweaks must be done to the deb
> package, wrong dependencies on the Steam deb package) so with the correct
> packages should work fine.
> The other one for HVM (windows) using qvm-pci.
>
> My plan is to get the hardware in about a couple of months, will let you
> know if works fine, emailing to update HCL.
>
> Many games try to get fullscreen, would it cause problems with the HVM?

The fullscreen inside of HVM will fill whatever it get as screen - VM window
in case of emulated GPU, real fullscreen in case of real GPU.
signature.asc

Alex Dubois

unread,
Jan 24, 2013, 3:54:50 AM1/24/13
to qubes...@googlegroups.com, qubes...@googlegroups.com, bradbury9
Hi Joanna,

I thought you said the dedicated GPU, if NVidia could act as an attack vector?

If not I'll give it a go too...

Alex

Joanna Rutkowska

unread,
Jan 24, 2013, 4:10:44 AM1/24/13
to qubes...@googlegroups.com, Alex Dubois, bradbury9
> On 23 Jan 2013, at 16:49, Marek Marczykowski <marm...@invisiblethingslab.com> wrote:
>
>> On 23.01.2013 17:41, bradbury9 wrote:
>>> Joanna, Marek, thanks for the info, greatly appreciated.
>>>
>>> I will try Joanna advice and, if failed, Marek's one. Will have two gaming
>>> HVM
>>>
>>> One for a fedora17 (or ubuntu) HVM. Steam has Fedora 17 and ubuntu
>>> packages/repo (with debian or mint some tweaks must be done to the deb
>>> package, wrong dependencies on the Steam deb package) so with the correct
>>> packages should work fine.
>>> The other one for HVM (windows) using qvm-pci.
>>>
>>> My plan is to get the hardware in about a couple of months, will let you
>>> know if works fine, emailing to update HCL.
>>>
>>> Many games try to get fullscreen, would it cause problems with the HVM?
>>
>> The fullscreen inside of HVM will fill whatever it get as screen - VM window
>> in case of emulated GPU, real fullscreen in case of real GPU.
>>
On 01/24/13 09:54, Alex Dubois wrote:> Hi Joanna,
>
> I thought you said the dedicated GPU, if NVidia could act as an attack
vector?
>
> If not I'll give it a go too...
>
> Alex
>

Well, sure, passing such complex device as a GPU to untrusted domain
does have some risks -- e.g. modern GPUs (some at least) do have their
own reflashable firmware and we never cannot be sure whether the
untrusted VM won't find a way to modify it (in fact we have confirmed
this in practice for some GPUs we tested). Then, the compromised
firmware, could theoretically attack the platform boot sequence, and I
don't think neither SRTM nor even Intel TXT could stop it then.

In practice I've never seen a successful attack of this kind, mostly
because GPU's internals are not documented for most (all?) GPUs, so even
if an attacker found a way to reflash the GPU's firmware, it would be
hard for them to actually write some sensible one, knowing nothing about
the underlying architecture.

Theoretically the same could happen when one passes other PCIe devices,
such as network cards, or USB controllers. On the other hand, it seems
much less likely to find a way to reflash firmware on such "simple*
devices -- at least I've never seen this happening in practice on modern
hardware (e.g. on integrated devices in laptops).

Here we talk about a situation when we pass GPU to one VM and leave it
there (this, of course, assumes we have two or more monitors also),
specifically we don't switch it constantly between Dom0 and some
untrusted VM. In this case (which is also hard to support without
special additional code in the hypervisor) the attack surface would
likely be much larger, I think.

My personal advice -- unless you are a Flame or Red October admin, or
otherwise high-profile target, you should probably be safe trying 2nd
GPU pass-thorugh to your gaming/personal HVM ;)

joanna.

signature.asc

Alex Dubois

unread,
Jan 24, 2013, 12:01:59 PM1/24/13
to Joanna Rutkowska, qubes...@googlegroups.com, bradbury9
OK I'll give it a go then...

Alex

bradbury9

unread,
Jan 27, 2013, 12:01:03 PM1/27/13
to qubes...@googlegroups.com, Joanna Rutkowska, bradbury9
Please, when you do it, please tell me about the results or send the info to the mailing list. I am considering in buiding a i7 with an expensive gpu to try qubes on it and if it does not work i will modify the build.

Alex Dubois

unread,
Jan 27, 2013, 6:31:35 PM1/27/13
to qubes...@googlegroups.com
Ok but very busy. Planed for test in 2 weeks...

Alex
--
 
 

bradbury9

unread,
Feb 15, 2013, 2:16:30 PM2/15/13
to qubes...@googlegroups.com, Joanna Rutkowska, bradbury9
Just tried passing GPU with "qvm-pci -a"... It turns out there is some problem passing GPU via qvm-pci. Looks like Xen does not like it very much when it comes with GPU's.

$qvm-start gamingLinux

libxl: error: libxl_pci.c:767:libxl_device_pci_reset The kernel doesn't support reset from sysfs for PCI device 0000:01:00.0
libxl: error: libxl_pci.c:726:do_pci_add xc_assign_device failed
libxl: error: libxl_pci.c:477:libxl__wait_for_device_model Device Model not ready
libxl: error: libxl_pci.c:641:libxl__pci_notify_device_model qemu refused to add device: 0000:01:00.0

The GPU is a Geforce GTX 680. Is there any qvm-pci option or can the HVM config files be edited to make Xen allow those commands?



El jueves, 24 de enero de 2013 18:01:59 UTC+1, Alex Dubois escribió:

bradbury9

unread,
Feb 15, 2013, 3:25:18 PM2/15/13
to qubes...@googlegroups.com, Joanna Rutkowska, bradbury9


El viernes, 15 de febrero de 2013 20:16:30 UTC+1, bradbury9 escribió:
Just tried passing GPU with "qvm-pci -a"... It turns out there is some problem passing GPU via qvm-pci. Looks like Xen does not like it very much when it comes with GPU's.

$qvm-start gamingLinux

libxl: error: libxl_pci.c:767:libxl_device_pci_reset The kernel doesn't support reset from sysfs for PCI device 0000:01:00.0
libxl: error: libxl_pci.c:726:do_pci_add xc_assign_device failed
libxl: error: libxl_pci.c:477:libxl__wait_for_device_model Device Model not ready
libxl: error: libxl_pci.c:641:libxl__pci_notify_device_model qemu refused to add device: 0000:01:00.0

The GPU is a Geforce GTX 680. Is there any qvm-pci option or can the HVM config files be edited to make Xen allow those commands?


I was looking in Xen PCI passthrough wiki[1] and I realized that my GPU does not seems to not support 'FL Reset', dunno what the hell it is, but it seems that is the way Xen implements the reset of the GPU, although it is not the only way (if vmware sees device does not support FLR it tries 2 or 3 other ways to reset it). Later I found some info there they recommend Ati cards and discourage Nvidia :-( [2], a list of Ati and Nvidia out-of-the-box working GPU's[3] and some Xen patches[2] that a guy created to make work a unsupported Ati.

[1]: http://wiki.xen.org/wiki/Xen_PCI_Passthrough#How_can_I_check_if_PCI_device_supports_FLR_.28Function_Level_Reset.29_.3F
[2]: http://wiki.xen.org/wiki/SecondaryGPUPassthrough
[3]: http://wiki.xen.org/wiki/XenVGAPassthroughTestedAdapters
[4]: http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/msg00441.html

Hope it helps others, as long as it will make me dualboot :-(

Any hint on how to dualboot with Qubes? Guess that the steps are:
1- Install Qubes leaving unpartitioned space
2- Install windows in the free space
3- Boot with Qubes installer and reinstall the grub. Dunno how to do this.

Cosmic Charade

unread,
Mar 2, 2013, 9:09:43 PM3/2/13
to qubes...@googlegroups.com, Joanna Rutkowska, bradbury9
I hope I am not rudely jumping in, I'm very new here (I just discovered Qubes!)

May I ask if the Nvidia binary driver working yet?  I'd also like to install Windows 8 and give that a Nvidia GTX GPU.  My motherboard or CPU also has built in Intel GPU.  What about for the Hypervisor and guest OS's overall?

How would it go having Nvidia binary driver installed in Linux, a guest OS and Windows OS?  Man my head hurts..

I didn't want to start a new thread in case I should have used an existing thread instead.

Thanks.. you guys all rock..

gorka -

unread,
Mar 3, 2013, 7:02:47 AM3/3/13
to qubes...@googlegroups.com

Forwarding to the list ;-)

---------- Forwarded message ----------
From: gorka - <ray.br...@gmail.com>
Date: 2013/3/3
Subject: Re: GPU passing to HVM (was: Re: [qubes-devel] Re: Question about windows HVM)
To: Cosmic Charade <cosmic...@gmail.com>


If you try with a a NVidia you have three choices:
a) Use one of the cards that the Xen guys have tested and discovered to work [1]. There are some NVidia cards in that list, but there are some of the Quadro branch (6000, 5000, 4000, 2000) and not the GTX branch. Ati cards are mostly supported.
b) There is some guy that got a GTX working in a recent windows guest, I think it was using Xen 4.1 and a windows 7 guest. He implemented into Xen the passthough patches in [2] and did some specific configuration to avoid the FLR calls. I read all the steps but didnt bookmark the link :-(. I just searched again. I think this is the link [3]
c) Using Xen 4.2 there is some weird steps that I haven tested and to be honest I fail to fully undestand, extracting the GPU EPPROM and patching Xen [4]. Be warned that Qubes uses 4.1, not 4.1 so b) option would apply.

Xen does use a only something called FLR to reset hardware and most NVidia cards do not have that FLR capability (dunno if any of them have it). My GTX 680 does not have it. There is some Xen configuration that can be made to workaround this issue. Thought I had posted it, my bad. Other virtualization alternatives, i think it was vmware, try FLR and, if device is not capable, they fallback to two other alternatives.

Hope this info helps.
I am not a linux programmer, so cannot try to patch Qubes with [2] patches withouth messing it. Besides maybe the secondary GPU passthougthrough is not the the desired way to get GPU acceleration, am i wrong Joanna, Marek?

2013/3/3 Cosmic Charade <cosmic...@gmail.com>

Cosmic Charade

unread,
Mar 4, 2013, 5:42:09 AM3/4/13
to qubes...@googlegroups.com
If I am reading this correctly, I have to pass through graphics from Windows to Xen (which is what I was thinking before I re-read this so maybe it now makes sense).

Ideally, there would be some driver I could just install in Windows that handles all that.

What about the hypervisor itself, doesn't that need an Nvidia hardware level driver?  At the moment it looks like the VM's are all software rendered, I'm not sure how I'd check though.

bradbury9

unread,
Mar 4, 2013, 9:38:32 AM3/4/13
to qubes...@googlegroups.com
Please, correct me if my guess is wrong.

Qubes: Xen is installed under linux. Runs windows VM
What you want: Xen is installed under _windows_. Runs windows VM

Is that correct? In that case the info you may find in this group to passthrough a secondary GPU to a windows HVM may be mostly useless. Some of the steps required (Xen patching, loading specific _linux_ kernel modules) are linux specific.

In my opinion, something similar would be needed if Xen is installed within windows, specially the loading modules (windows nvidia drivers) part, but I am not an expert in Xen. I would suggest you could find some help in official Xen wiki and devel mailing list if trying to do it in a Windows -> Windows passthrough.

Joanna Rutkowska

unread,
Mar 4, 2013, 1:08:55 PM3/4/13
to qubes...@googlegroups.com, Cosmic Charade
On 03/04/13 11:42, Cosmic Charade wrote:
> If I am reading this correctly, I have to pass through graphics from
> Windows to Xen (which is what I was thinking before I re-read this so maybe
> it now makes sense).
>
> Ideally, there would be some driver I could just install in Windows that
> handles all that.
>

Yes, ideally the driver from nvidia.com.

> What about the hypervisor itself, doesn't that need an Nvidia hardware
> level driver?

The hypervisor needs to know nothing about the specifics of the device
you passthrough.

> At the moment it looks like the VM's are all software
> rendered, I'm not sure how I'd check though.
>

I have no idea what you mean by "software rendered" in this context.

joanna.
>> 2013/3/3 Cosmic Charade <cosmic...@gmail.com <javascript:>>
signature.asc

Joanna Rutkowska

unread,
Mar 4, 2013, 1:12:00 PM3/4/13
to qubes...@googlegroups.com, bradbury9
On 03/04/13 15:38, bradbury9 wrote:
> Please, correct me if my guess is wrong.
>
> Qubes: Xen is installed under linux. Runs windows VM

Correcting, as requested. Xen cannot be installed "under Linux" -- after
all it's a _baremetal_ hypervisor, right? Ignoring the rest of the post.

joanna.

signature.asc

Cosmic Charade

unread,
Mar 4, 2013, 3:27:07 PM3/4/13
to qubes...@googlegroups.com, bradbury9
ah yeah, Xen is not installed 'under' anything, it 'is' the very thing that other things are installed 'under' - hence the term 'hypervisor'.

So if I install the binary Nvidia driver within the Windows 8 environment, won't this break something? Or may it in fact work?  I'm not so concerned about something as ultra complex as games, which I can boot in to a native Windows 8 for, I just want the graphics card to support at least desktop compositing and playing videos and whatever.

As for 'software rendering' - I mean in the days of yore in Linux when hardware graphics often didn't work for lack of a driver, so all the rendering was done in software or by the CPU instead of the GPU and it showed - as in windows not being smooth and just looking like the CPU rather than GPU was doing all the graphics work.  Which is not what CPU's are for.  And I don't want to spend my days living in a text terminal if I can help it (as useful as I find a terminal, but within a GUI environment thank you!)

So if Xen doesn't need a graphics driver, where would I install it?  Can I install the Nvidia graphics driver under the Fedora VM and Windows HVM?  Won't those two VM's then clash or something?  Thats why I wondered if the hypervisor had to 'mangle' all the graphics stuff together from all the various VM's.

And on the Wiki page, it says Nvidia driver not compatible with Xen - is this true?

Joanna Rutkowska

unread,
Mar 4, 2013, 4:19:53 PM3/4/13
to qubes...@googlegroups.com, Cosmic Charade, bradbury9
On 03/04/13 21:27, Cosmic Charade wrote:
> ah yeah, Xen is not installed 'under' anything, it 'is' the very thing that
> other things are installed 'under' - hence the term 'hypervisor'.
>
> So if I install the binary Nvidia driver within the Windows 8 environment,
> won't this break something? Or may it in fact work? I'm not so concerned
> about something as ultra complex as games, which I can boot in to a native
> Windows 8 for, I just want the graphics card to support at least desktop
> compositing and playing videos and whatever.
>
> As for 'software rendering' - I mean in the days of yore in Linux when
> hardware graphics often didn't work for lack of a driver, so all the
> rendering was done in software or by the CPU instead of the GPU and it
> showed - as in windows not being smooth and just looking like the CPU
> rather than GPU was doing all the graphics work. Which is not what CPU's
> are for. And I don't want to spend my days living in a text terminal if I
> can help it (as useful as I find a terminal, but within a GUI environment
> thank you!)
>
> So if Xen doesn't need a graphics driver, where would I install it?

In your Windows HVM.
j.
signature.asc

Cosmic Charade

unread,
Mar 6, 2013, 11:44:42 PM3/6/13
to qubes...@googlegroups.com, Cosmic Charade, bradbury9
OK this is my lack of technical understanding coming through.

So the Xen hypervisor does *not* require a graphics driver, but each VM does?  What would happen if I installed the Linux Nvidia binary driver in the Fedora default VM's, and the binary Nvidia driver in a Windows 8 VM?  Wouldn't they clash or something?  I don't want to play games (I'll use a bare metal Windows for that), but I may want to watch some basic / streaming media or full screen video (not DRM protected blu-ray's - but possibly .mkv or other video files).

Radoslaw Szkodzinski

unread,
Mar 7, 2013, 1:50:10 AM3/7/13
to qubes...@googlegroups.com, Cosmic Charade, bradbury9
On Thu, Mar 7, 2013 at 5:44 AM, Cosmic Charade <cosmic...@gmail.com> wrote:
> OK this is my lack of technical understanding coming through.
>
> So the Xen hypervisor does *not* require a graphics driver, but each VM
> does? What would happen if I installed the Linux Nvidia binary driver in
> the Fedora default VM's, and the binary Nvidia driver in a Windows 8 VM?
> Wouldn't they clash or something? I don't want to play games (I'll use a
> bare metal Windows for that), but I may want to watch some basic / streaming
> media or full screen video (not DRM protected blu-ray's - but possibly .mkv
> or other video files).

You can redirect the GPU only to one virtual machine at a time. The
real question is whether the driver correctly resets the card, so you
can attach it again.
For example Catalyst drivers did not (10.12 or so - first version with
Radeon 7950 support) - but xm's old way of reset worked well. Perhaps
someone should patch that into xl as well for cards w/o FLR like that
one.

Theoretically Qubes GUId may be just about fast enough for full screen
video, if your CPU is fast enough to decode it in software with some
remaining power, as the GUI protocol is relatively CPU intensive.
It is too slow for fullscreen Flash though - that thing has very slow
software decoding and/or scaling.
(CPU here: Xeon E3 1275)

--
Radosław Szkodziński

Cosmic Charade

unread,
Mar 7, 2013, 3:36:53 AM3/7/13
to qubes...@googlegroups.com, Cosmic Charade, bradbury9


On Thursday, 7 March 2013 17:50:10 UTC+11, Radosław Szkodziński wrote:

You can redirect the GPU only to one virtual machine at a time. The
real question is whether the driver correctly resets the card, so you
can attach it again.

Works for me..  So I just install the binary drivers in to each VM environment and I'm good to go.
 
For example Catalyst drivers did not (10.12 or so - first version with
Radeon 7950 support) - but xm's old way of reset worked well. Perhaps
someone should patch that into xl as well for cards w/o FLR like that
one.

And here's the catch :-)  Only one way to find out I suppose.
 
Theoretically Qubes GUId may be just about fast enough for full screen
video, if your CPU is fast enough to decode it in software with some
remaining power, as the GUI protocol is relatively CPU intensive.

Qubes GUID?  You mean the X server and the like in the Fedora VM's or by the hypervisor itself?  Ideally software decoding would be shunted to hardware wherever possible as most PC's have this sort of hardware built in now (decode acceleration), but even so the binary driver run everything just fine I would have thought.
 
It is too slow for fullscreen Flash though - that thing has very slow
software decoding and/or scaling.
(CPU here: Xeon E3 1275)

Should be fine with binary drivers, I'll find out.
 
--
Radosław Szkodziński

bradbury9

unread,
Mar 7, 2013, 5:00:21 AM3/7/13
to qubes...@googlegroups.com, Cosmic Charade, bradbury9

El jueves, 7 de marzo de 2013 09:36:53 UTC+1, Cosmic Charade escribió:


On Thursday, 7 March 2013 17:50:10 UTC+11, Radosław Szkodziński wrote:

You can redirect the GPU only to one virtual machine at a time. The
real question is whether the driver correctly resets the card, so you
can attach it again.

Works for me..  So I just install the binary drivers in to each VM environment and I'm good to go.
 
For example Catalyst drivers did not (10.12 or so - first version with
Radeon 7950 support) - but xm's old way of reset worked well. Perhaps
someone should patch that into xl as well for cards w/o FLR like that
one.

And here's the catch :-)  Only one way to find out I suppose.

That's the main problem with most NVidia cards.
 

Cosmic Charade

unread,
Mar 7, 2013, 10:16:13 PM3/7/13
to qubes...@googlegroups.com

That blows...

Is there any way to compensate for the lack of a reset command in NVidia cards?

I'm fine with hardware lock to each VM as they are used although I'm not sure how this would work with windows from different VMs displaying simultaneously.

bradbury9

unread,
Mar 8, 2013, 2:49:45 AM3/8/13
to qubes...@googlegroups.com
On the links I provided there was a guy that workarounded that problem configuring the HVM to not to reset the device, but I share Radoslaw opinion. It would be wiser to patch the code. Is vmware code publicy accesible? they do two different alternative ways to reset if FLR is not available.

Radoslaw Szkodzinski

unread,
Mar 8, 2013, 11:08:57 AM3/8/13
to qubes...@googlegroups.com
On Fri, Mar 8, 2013 at 8:49 AM, bradbury9 <ray.br...@gmail.com> wrote:
> On the links I provided there was a guy that workarounded that problem
> configuring the HVM to not to reset the device, but I share Radoslaw
> opinion. It would be wiser to patch the code. Is vmware code publicy
> accesible? they do two different alternative ways to reset if FLR is not
> available.

Xend has the right reset code, tries: FLR, then P-states warm reset,
then P-states power off, and if all fails, PCI bus reset.
This is obviously available.

--
Radosław Szkodziński

Cosmic Charade

unread,
Mar 8, 2013, 3:45:01 PM3/8/13
to qubes...@googlegroups.com

PCI bus reset sounds a bit harsh? Could that damage hardware in any way?

--
You received this message because you are subscribed to a topic in the Google Groups "qubes-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qubes-devel/MfHy2jmXhXM/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to qubes-devel...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Radoslaw Szkodzinski

unread,
Mar 8, 2013, 4:20:45 PM3/8/13
to qubes...@googlegroups.com
On Fri, Mar 8, 2013 at 9:45 PM, Cosmic Charade <cosmic...@gmail.com> wrote:
> PCI bus reset sounds a bit harsh? Could that damage hardware in any way?

No, at worst it will result in a hardware hang with associated file
system damage, if any at all.
Perhaps even necessitating a full power cycle.

--
Radosław Szkodziński

Cosmic Charade

unread,
Mar 8, 2013, 7:37:17 PM3/8/13
to qubes...@googlegroups.com

So it is a harsh method but could work then... may need a way to soft restart PC if it hangs then

kod.c...@gmail.com

unread,
Dec 15, 2013, 12:21:49 PM12/15/13
to qubes...@googlegroups.com

Xend has the right reset code, tries: FLR, then P-states warm reset,
then P-states power off, and if all fails, PCI bus reset.
This is obviously available.

--
Radosław Szkodziński

I agree, this is most probably available unless something in kernel is off, or if not using xend, because i think with xl things got broken. Maybe xl will get fixed in future, but doubtly, and for the time being is probably better to have xend.

IMHO, the security issue of VGA passthrough might have other perspective. If there is something there smart enough to encode itself in the video card, it will boot by simple power on, and has own resources and physical access regardless if its used as device or not. Let your imagination wild, write your own microcode etc. I think this is why the idea is so attractive. So the security might be already compromised by the video card just *being there*. If it is passed throguh, actually might just help keeping connectivity busy, might force ware into hiding mode. So dunno how much this is right or wrong, but *my os accessing the video card* might just not be same with *video card accessing me*. At the very least i am inclined to think like so.

Hard virtualization is coming and imho it will bring many changes, weather we like it or not. Ex many OS-es will become bundled apps. Degraded from os to apps status. Want some programs for say electronics, fire up fedora-electronic-lab in a vm, and you got it all, but thats not an os anymore, its a bundle of apps that just dont bother with incompatibilities. Schools use spins that are tailored for certain topics. Are you a game maker, make your own os to be your game engine. Ultimate cross-platform. Not there yet, but coming. I think this aspect and what it means is largely underestimated. If someone today would officially support vga passthrough out of box, it would gain an immense momentum right now. Or will be bought out by another co, probably to delay things and help ms's hyper-v. But doing the same thing 2-3 years from now when everyone will have the feature, it wont mean anything then. Again this is just my opinion.

Radoslaw Szkodzinski

unread,
Dec 15, 2013, 1:50:52 PM12/15/13
to kod.c...@gmail.com, qubes...@googlegroups.com
That old thread and I got pinged.

Of course, it has issues like any hardware passing. If the hardware
has programmable firmware that survives reboots/resets, then malware
could encode into it and exploit the drivers.
Therefore you should not attach the device to any more secure domain
afterwards; passing it across domains of the same security degree
should be fine though.
Dom0 does not have to actually run the driver for this device though,
but it is an avenue for an attack on the EFI code. Hard to pull off
though.

Hardware virtualization for GPUs is still some ways off, look at how
long it took for CPUs to handle properly.

R.

kod.c...@gmail.com

unread,
Dec 15, 2013, 5:42:53 PM12/15/13
to qubes...@googlegroups.com, kod.c...@gmail.com

I like that. It makes total sense to me to have a secondary video cards locked down in least secure area. If i have a win vm with vga on it, i will certainly play alot of games and each of them will be totally insecure :) The whole point of having it like that is coz the low chances that malware is able to jump the virt jail, jump across os-es, or else. If we do have a malware at a difficulty degree that is able to encode itself into the bios, then probably it is at least equally capable to do the other things, or done it already.

Again, with xend this should be already possible for Qubes os, i mean with a secondary video card. Can we get some sort of confirmation if it is or not possible - and i dont mean supported, just possible atm.
Does beta3 still use xend api, and can this be played with, any caveats for this under Qubes os?

David Schissler

unread,
Dec 15, 2013, 9:22:51 PM12/15/13
to qubes...@googlegroups.com, kod.c...@gmail.com
Very true.  Who could have thought that GNU/Hurd would would be usable while being virtualized on top of a hypervisor with a GNU/Linux graphical front end.  Maybe funnier things have happened?
 

David Schissler

unread,
Dec 15, 2013, 9:32:04 PM12/15/13
to qubes...@googlegroups.com, kod.c...@gmail.com


A British company is selling upgraded Thinkpad X60 machines (Core 2 64 bit) with the BIOS replaced by coreboot.
http://shop.gluglug.org.uk/product/ibm-lenovo-thinkpad-x60-coreboot/

france...@gmail.com

unread,
Dec 25, 2013, 12:32:06 PM12/25/13
to qubes...@googlegroups.com, kod.c...@gmail.com
So... has it been patched? I have a Geforce 740m, in addition to the one integrated in the CPU (i7 Haswell), and I run Beta 3. If I create a HVM and select the GPU to be passed through in the settings, should the guest work with the video card as if it was installed on bare metal? Or will strange things happen?

Markus F

unread,
Jan 16, 2014, 1:34:29 PM1/16/14
to qubes...@googlegroups.com, kod.c...@gmail.com, france...@gmail.com

Has anyone managed to completely pass any graphics card to a HVM in qubes yet? Or has this thread firmly settled on not-possible-right-now?


— 

 

I'm building a PC and would like to use Qubes. Since this means getting components that play nice with VT-d anyway, it seems a shame not to at least try GPU passthrough rather than perpetual system swapping. To this end I am considering getting an intel processor with onboard graphics for Qubes, and an ATI card (R9 280X) to passthrough to a Win8 HVM (with another monitor connection to the card). 


Right now, I have zero experience with qubes (this will be remedied!), but reasons I think this isn't just a mad wish:

  • Xen wiki about Xen 4.1.1: "Passing thru AMD/ATI Radeon/FirePro/FireGL adapters as secondary to the VM should work out-of-the-box (you need latest ATI gfx drivers in the VM). Secondary means the Xen Qemu-dm virtual Cirrus adapter is the primary where you see the VM BIOS etc when powering on the VM, and the passthru adapter is secondary, so you can enable/use it after the OS in the VM has started and you've installed drivers for the adapter."
  • A xen user's success story / tutorial with a "7970/R9 280X" with Ubuntu and Windows 7. 
  • Everyone reporting a failures seems to be talking about nvidia GPUs, which are known to misbehave under xen for a number of reasons.

Does that leave any reason why these settings shouldn't work in qubes? Of course, qubes isn't just xen, so I imagine the differences are where the trouble lies, but I don’t yet know where all the differences lie.


Security-wise, again I understand that I understand basically nothing, but from Joanna’s reply above, it seems to me that there isn’t too much danger as long as I never assign the GPU to any higher security areas.

Alex Dubois

unread,
Jan 16, 2014, 2:54:28 PM1/16/14
to Markus F, qubes...@googlegroups.com, kod.c...@gmail.com, france...@gmail.com
To be tested with xen kernel modifications for HVM vm only

I believe to be the status.

Alex
--
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...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
Visit this group at http://groups.google.com/group/qubes-devel.

Radoslaw Szkodzinski

unread,
Jan 17, 2014, 9:38:42 AM1/17/14
to Markus F, qubes...@googlegroups.com, Cipher Kod, france...@gmail.com
I've done it a long, long time ago with Radeon 7950 as a secondary
card, but I had to start the VM using xm and not xl, manually.
Otherwise the card wouldn't be properly reset on VM shutdown and any
future attempt to start a Windows VM with it would cause a hardware
hang, while Linux ones would oops.

I'll retest this setup soon, but not on Qubes right now.

R.

coderman

unread,
Jan 17, 2014, 4:31:00 PM1/17/14
to Radoslaw Szkodzinski, Markus F, qubes...@googlegroups.com, Cipher Kod, france...@gmail.com
i had success with this same setup, a pair of 6950's, with the second
manually started via xm with specific configuration.

important: disable SLI! i could not get this to work reliably when
SLI was linked up...


this was R1B1, i have not tried since. i may have time to try again,
if Radoslaw does not beat me to it.


best regards,

guyfaw...@yandex.ru

unread,
Sep 26, 2014, 9:49:54 PM9/26/14
to qubes...@googlegroups.com, astra...@gmail.com, markus...@gmail.com, kod.c...@gmail.com, france...@gmail.com
Something I found on xen forum about how to determine if FLR function exists on your devices. So my question is does your Radeon 7950 support FLR and if not how did you manage to reset  using xm and not xl, manually ? my current set up is  t420s with  Integrated graphics  [intel hd graphics 3000 ( which is basically integrated graphics on cpu)] I7-2620m then on top of this there exists on the mother board also a Nvidia NVS 4200M. Which I want to pass through to my windows 7 vm so I can fully utilize this for gaming. what do you guys think ? before doing a format on this windows system I would like to know your opinion.
How can I check if PCI device supports FLR (Function Level Reset)?

Run "lspci -vv" (in dom0) and check if the device has "FLReset+" in the
DevCap field.

If you are Ubuntu/Debian user don't forget to add sudo at front,
otherwise,
you won't get the result you should get.

sudo lspci -vv | egrep -i --colour flreset

The above line should get root access for lspci program and show color
with
flreset it found from output If you see output with "FLReset-" then your PCI device don't support FLR function. If output has "FLReset+" then it does.

Radoslaw Szkodzinski

unread,
Sep 27, 2014, 3:51:17 AM9/27/14
to guyfaw...@yandex.ru, qubes...@googlegroups.com, Markus Führer, Cipher Kod, Francesco Dondi
7950 does not support FLR. However, the card reacts well to PCI reset,
as used to be done by xm - returns to a fully clean state.
(In linux, you will need to reload the drivers for it to work again -
the firmware has to be reuploaded.)

xl depends (or depended?) on the guest OS to reset the card, so you
have to reset the card manually via sysfs if using Windows or fglrx.
(radeon open driver resets the card properly when unloaded)
If you don't reset the card properly, it will hardware hang your
system if you try to use it in Windows and Linux will spout kernel
error messages.

R.

guyfaw...@yandex.ru

unread,
Sep 27, 2014, 4:10:52 AM9/27/14
to qubes...@googlegroups.com, guyfaw...@yandex.ru, markus...@gmail.com, kod.c...@gmail.com, france...@gmail.com
So with my above mentioned set up do you think that I will be able to pass the NVS 4200M to the windows 7 vm and since it does not support FLR what do you recommend so I am able to utilize this fully in the vm ? I am new to linux and all, my current set up is win7 with truecrypt, boot loader on thumb drive. with AES hardware encryption on i7 and bios tpm fingerprint. But I see that the future is in hypervisor's so I want to migrate to such a platform. I bought the t420s soly' on the fact that it was listed in the Qubes os supported hardware. So I would like to utilize this new system much as I can, preferably not to dual boot for gaming, would be defeating the purpose of a hypervisor.

Joanna Rutkowska

unread,
Sep 27, 2014, 4:42:50 AM9/27/14
to Radoslaw Szkodzinski, guyfaw...@yandex.ru, qubes...@googlegroups.com, Markus Führer, Cipher Kod, Francesco Dondi
On 09/27/14 09:50, Radoslaw Szkodzinski wrote:
> 7950 does not support FLR. However, the card reacts well to PCI reset,
> as used to be done by xm - returns to a fully clean state.
> (In linux, you will need to reload the drivers for it to work again -
> the firmware has to be reuploaded.)
>
> xl depends (or depended?) on the guest OS to reset the card,

Where do you get this info from?
signature.asc

Radoslaw Szkodzinski

unread,
Sep 27, 2014, 4:46:43 AM9/27/14
to Joanna Rutkowska, guyfawkes511, qubes...@googlegroups.com, Markus Führer, Cipher Kod, Francesco Dondi
Got it a long time ago from Konrad when I asked what is the difference
- why xl didn't work and xm did.
Not sure it's still accurate though.

R.

Joanna Rutkowska

unread,
Sep 27, 2014, 4:52:35 AM9/27/14
to Radoslaw Szkodzinski, guyfawkes511, qubes...@googlegroups.com, Markus Führer, Cipher Kod, Francesco Dondi
> On 09/27/14 09:50, Radoslaw Szkodzinski wrote:
>> 7950 does not support FLR. However, the card reacts well to PCI reset,
>> as used to be done by xm - returns to a fully clean state.
>> (In linux, you will need to reload the drivers for it to work again -
>> the firmware has to be reuploaded.)
>>
>> xl depends (or depended?) on the guest OS to reset the card,

On 09/27/14 10:42, Joanna Rutkowska wrote:
> Where do you get this info from?

That would be totally wrong, as the guest is normally untrusted. If you
cannot point out to specific code to support your statements, and/or are
unsure about what you're talking about, please do not make them sound
authoritative.

And, please, don't remove quoted text, it's useful for referenced. Not
everybody is reading this via Google groups Web interface.

joanna.

signature.asc

guyfawkes

unread,
Sep 27, 2014, 6:23:03 AM9/27/14
to qubes...@googlegroups.com, astra...@gmail.com, guyfaw...@yandex.ru, markus...@gmail.com, kod.c...@gmail.com, france...@gmail.com
So with my above mentioned set up do you think that I will be able to pass the NVS 4200M to the windows 7 vm and since it does not support FLR what do you recommend so I am able to utilize this fully in the vm ? I am new to linux and all, my current set up is win7 with truecrypt, boot loader on thumb drive. with AES hardware encryption on i7 and bios tpm fingerprint. But I see that the future is in hypervisor's so I want to migrate to such a platform. I bought the t420s soly' on the fact that it was listed in the Qubes os supported hardware. So I would like to utilize this new system much as I can, preferably not to dual boot for gaming, would be defeating the purpose of a hypervisor.

Radoslaw Szkodzinski

unread,
Sep 27, 2014, 8:52:41 AM9/27/14
to guyfawkes, qubes...@googlegroups.com, Markus Führer, Cipher Kod, Francesco Dondi
On Sat, Sep 27, 2014 at 12:23 PM, guyfawkes <guyfaw...@yandex.ru> wrote:
> So with my above mentioned set up do you think that I will be able to pass
> the NVS 4200M to the windows 7 vm and since it does not support FLR what do
> you recommend so I am able to utilize this fully in the vm ? I am new to
> linux and all, my current set up is win7 with truecrypt, boot loader on
> thumb drive. with AES hardware encryption on i7 and bios tpm fingerprint.
> But I see that the future is in hypervisor's so I want to migrate to such a
> platform. I bought the t420s soly' on the fact that it was listed in the
> Qubes os supported hardware. So I would like to utilize this new system much
> as I can, preferably not to dual boot for gaming, would be defeating the
> purpose of a hypervisor.

It should work with new Xen. I'm not sure which version is in Qubes R3
alpha though, probably still too old.

> On Saturday, September 27, 2014 3:52:35 AM UTC-5, joanna wrote:
>>
>> > On 09/27/14 09:50, Radoslaw Szkodzinski wrote:
>> >> 7950 does not support FLR. However, the card reacts well to PCI reset,
>> >> as used to be done by xm - returns to a fully clean state.
>> >> (In linux, you will need to reload the drivers for it to work again -
>> >> the firmware has to be reuploaded.)
>> >>
>> >> xl depends (or depended?) on the guest OS to reset the card,
>>
>> On 09/27/14 10:42, Joanna Rutkowska wrote:
>> > Where do you get this info from?
>>
>> On 09/27/14 10:46, Radoslaw Szkodzinski wrote:
>> > Got it a long time ago from Konrad when I asked what is the difference
>> > - why xl didn't work and xm did.
>> > Not sure it's still accurate though.
>> >
>>
>> That would be totally wrong, as the guest is normally untrusted. If you
>> cannot point out to specific code to support your statements, and/or are
>> unsure about what you're talking about, please do not make them sound
>> authoritative.
>>
>> And, please, don't remove quoted text, it's useful for referenced. Not
>> everybody is reading this via Google groups Web interface.
>>
>> joanna.
>>

That was the answer I got around Xen 4.2 time though... Qubes is still
using 4.1.x, right?
So it does not run a full PCI reset on relinquishing passthrough
devices, only FLR.
Insecure indeed if a device does not support FLR.

It was changed around Xen 4.3, now libxl calls into dom0 kernel for
PCI reset, which does all kinds of resets.

--
Radosław Szkodziński

Joanna Rutkowska

unread,
Sep 27, 2014, 9:15:24 AM9/27/14
to qubes...@googlegroups.com
Xen has been using PCI bus reset as part of do_FLR() since at least 3.x
(was doing that in case the device didn't support FLR). Please back up
your claims with specific code refs, or stop spreading misinformation.

Thanks,
joanna.

signature.asc

Joanna Rutkowska

unread,
Sep 27, 2014, 9:17:04 AM9/27/14
to guyfaw...@yandex.ru, qubes...@googlegroups.com, markus...@gmail.com, kod.c...@gmail.com, france...@gmail.com
I'm not sure I get your idea -- so your laptop has 2 GPUs, but 1
monitor, correct? Even if you manage to passthrough one of the GPUs to a
VM, still, you have just one monitor, right? Is there any control
mechanism that you can easily use to select which GPU is currently
connected to the monitor?

joanna.

On 09/27/14 10:10, guyfaw...@yandex.ru wrote:
> So with my above mentioned set up do you think that I will be able to pass
> the *NVS 4200M to the windows 7 vm and since it does not support FLR what
> do you recommend so I am able to utilize this fully in the vm ? I am new to
> linux and all, my current set up is win7 with truecrypt, boot loader on
> thumb drive. with AES hardware encryption on i7 and bios tpm fingerprint.
> But I see that the future is in hypervisor's so I want to migrate to such a
> platform. I bought the t420s soly' on the fact that it was listed in the
> Qubes os supported hardware. So I would like to utilize this new system
> much as I can, preferably not to dual boot for gaming, would be defeating
> the purpose of a hypervisor.*
signature.asc

Radoslaw Szkodzinski

unread,
Sep 27, 2014, 9:45:22 AM9/27/14
to Joanna Rutkowska, qubes...@googlegroups.com
Which is not true.

First of all, xl does not properly force a FLR:
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/libxl/libxl_pci.c;h=61bef12c62c83dcc61730726ad88891c720b257a;hb=8231a6762ad70aa00f54cb53424b7c850d4c286b#l722
(4.1.6.1, as in Qubes R2, maybe R3 is newer?)

vs fix (broken, see reference, trivial):
http://lists.xen.org/archives/html/xen-devel/2014-06/msg03107.html

Feel free to apply the patch.
This requires a patch set which your kernel might not have:
http://lists.xenproject.org/archives/html/xen-devel/2014-07/msg01111.html

Unpatched 3.12.x kernel (as used in Qubes) will not properly force a
reset on a pciback device either via sysfs (because the device is busy
thanks to pciback) or via do_flr even if you write to the right path
(because there are bugs).

My workaround (until I've updated Xen) was to unbind it from pciback,
reset via sysfs, run a hotplug add then pciback it again.
I should've looked into the code instead, could've spotted this bug.

Of course, that was completely insecure, because for a moment the
device was attached to dom0.

--
Radosław Szkodziński

Chris Olin

unread,
Oct 16, 2014, 11:42:38 AM10/16/14
to qubes...@googlegroups.com
For the last couple of months, I've been using Qubes on an HP EliteBook (using it right now, actually) with no impressive graphics and the motherboard is capped at 8GB of RAM. With the high possibility of a new job with significant more pay, I've been looking for an "all in one" laptop to do literally "everything" on in terms of virtualizing demo/testing servers.

I'm not much of a gamer, but the laptop I found is a gaming laptop (for some reason, only gaming laptops have 32GB of memory) and supposedly has a graphics processor built into the i7 in it (http://forum.notebookreview.com/msi/762800-official-msi-gt72-dominator-pro-gtx-980m-owner-s-lounge.html). While I'm not much of a gamer, it'd be a shame to let the nVidia card just sit there, wasting away. If and when I do end up buying this laptop, I'll see if gaming on a HVM is a possible and viable option.

Franz

unread,
Oct 16, 2014, 11:15:29 PM10/16/14
to Chris Olin, qubes...@googlegroups.com
Even a laptop with a free expresscard slot may allow a linux compatible graphic card slot:
http://www.amazon.com/PE4H-EC2C-Passive-adapter-ver2-4-ExpressCard/dp/B008I71HXQ
best
Fran

On Thu, Oct 16, 2014 at 1:42 PM, Chris Olin <ch...@chrisolin.com> wrote:
For the last couple of months, I've been using Qubes on an HP EliteBook (using it right now, actually) with no impressive graphics and the motherboard is capped at 8GB of RAM. With the high possibility of a new job with significant more pay, I've been looking for an "all in one" laptop to do literally "everything" on in terms of virtualizing demo/testing servers.

I'm not much of a gamer, but the laptop I found is a gaming laptop (for some reason, only gaming laptops have 32GB of memory) and supposedly has a graphics processor built into the i7 in it (http://forum.notebookreview.com/msi/762800-official-msi-gt72-dominator-pro-gtx-980m-owner-s-lounge.html). While I'm not much of a gamer, it'd be a shame to let the nVidia card just sit there, wasting away. If and when I do end up buying this laptop, I'll see if gaming on a HVM is a possible and viable option.

--
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...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
Visit this group at http://groups.google.com/group/qubes-devel.
For more options, visit https://groups.google.com/d/optout.

thibau...@gmail.com

unread,
Oct 9, 2015, 7:28:58 AM10/9/15
to qubes-devel
Hello guys, i am currently building a new machine with vt-d to use passthrough with my gpu.
I am a developper so i wanted to put all the gaming stuff into a different os so i could secure my main os.
Now i just discovered qubes, could someone confirm to me that passthrough solutions with xen will work just fine with qubes? 
I read things about xen who might not be compatible with non multi os gpu and i have a gtx 980 ti.
Any answer would be more than welcome :)

Le mercredi 23 janvier 2013 13:51:08 UTC+1, bradbury9 a écrit :
Hi,

I want to give qubes a try but actually dont have any decent hardware to try it on. On another side I am planning to get a gaming desktop computer so I was thinking maybe I could combine both needs (aka, gaming qubes). There go my questions...

- Could be possible to get a windows HVM with DirectX (9.0C) and big amount of RAM (minimum 6 GB)? If not, does default qubes installation allow dual boot?
- Any plans on allowing HVM get fullscreen or is there any security risk?
- Is it posible to get a templateVM (probably ubuntu or mint) with OpenGL?

BTW, you guys are doing a great job providing security to regular users.

Ascii Wolf

unread,
Jan 8, 2020, 11:16:19 AM1/8/20
to qubes-devel
Looks like there was not any update about this for a long time. I am also interested in knowing what is the state of GPU/PCI passthrough in Qubes OS.
Reply all
Reply to author
Forward
0 new messages