Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upCannot use a USB camera #4035
Comments
andrewdavidwong
added
bug
C: other
labels
Jun 26, 2018
andrewdavidwong
added this to the Release 4.0 updates milestone
Jun 26, 2018
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
jpouellet
Jun 30, 2018
Contributor
Might this be an issue with the client you are trying to use to interact with your camera? Have you tried passing the PCI device to a VM with the same template to confirm whether qubes-usb-proxy is in fact the issue?
I've used usb-passthrough for a webcam recently and it worked for me.
Closing and re-opening the device can sometimes leave it in an inconsistent state and unable to use, but I've never had trouble with the first consumer of a device on a given boot.
|
Might this be an issue with the client you are trying to use to interact with your camera? Have you tried passing the PCI device to a VM with the same template to confirm whether qubes-usb-proxy is in fact the issue? I've used usb-passthrough for a webcam recently and it worked for me. Closing and re-opening the device can sometimes leave it in an inconsistent state and unable to use, but I've never had trouble with the first consumer of a device on a given boot. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
abis866i
Jun 30, 2018
Thank you for looking into this. Here is my setting: personal and untrusted VMs are using the Debian template while the rest are using the Fedora template. I have to admit that I do not have too much knowledge into the Linux area so, please guide me through the process. I have removed the PCI from the sys-net where it was attached before. In this case, I try to attach the PCI to the "work" VM which is Fedora, but I get an error. Please see below.
[user@dom0 ~]$ qvm-pci
BACKEND:DEVID DESCRIPTION USED BY
dom0:00_00.0 Host bridge: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers
dom0:00_02.0 VGA compatible controller: Intel Corporation HD Graphics 530
dom0:00_08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core Processor Gaussian Mixture Model
dom0:00_14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller sys-net (no-strict-reset=True)
dom0:00_14.2 Signal processing controller: Intel Corporation Sunrise Point-H Thermal subsystem
dom0:00_15.0 Signal processing controller: Intel Corporation Sunrise Point-H Serial IO I2C Controller #0
dom0:00_15.1 Signal processing controller: Intel Corporation Sunrise Point-H Serial IO I2C Controller #1
dom0:00_16.0 Communication controller: Intel Corporation Sunrise Point-H CSME HECI #1
dom0:00_17.0 SATA controller: Intel Corporation Sunrise Point-H SATA controller [AHCI mode]
dom0:00_1c.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #1
dom0:00_1c.2 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #3
dom0:00_1c.5 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #6
dom0:00_1c.7 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #8
dom0:00_1d.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #9
dom0:00_1d.2 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #11
dom0:00_1d.3 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #12
dom0:00_1d.4 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #13
dom0:00_1e.0 Signal processing controller: Intel Corporation Sunrise Point-H Serial IO UART #0
dom0:00_1f.0 ISA bridge: Intel Corporation Sunrise Point-H LPC Controller
dom0:00_1f.2 Memory controller: Intel Corporation Sunrise Point-H PMC
dom0:00_1f.3 Audio device: Intel Corporation Sunrise Point-H HD Audio
dom0:00_1f.4 SMBus: Intel Corporation Sunrise Point-H SMBus
dom0:02_00.0 USB controller: ASMedia Technology Inc. ASM1142 USB 3.1 Host Controller sys-net (no-strict-reset=True)
dom0:03_00.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 Host Controller
dom0:04_00.0 Network controller: Qualcomm Atheros AR93xx Wireless Network Adapter sys-net
dom0:06_00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge
dom0:07_01.0 Multimedia audio controller: C-Media Electronics Inc CMI8738/CMI8768 PCI Audio
dom0:08_00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller sys-net
dom0:09_00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961
[user@dom0 ~]$ qvm-pci attach --persistent --option permissive=true --option no-strict-reset=true work dom0:03_00.0
Can't attach PCI device to VM in pvh mode
abis866i
commented
Jun 30, 2018
|
Thank you for looking into this. Here is my setting: personal and untrusted VMs are using the Debian template while the rest are using the Fedora template. I have to admit that I do not have too much knowledge into the Linux area so, please guide me through the process. I have removed the PCI from the sys-net where it was attached before. In this case, I try to attach the PCI to the "work" VM which is Fedora, but I get an error. Please see below. [user@dom0 ~]$ qvm-pci [user@dom0 ~]$ qvm-pci attach --persistent --option permissive=true --option no-strict-reset=true work dom0:03_00.0 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
jpouellet
Jul 1, 2018
Contributor
Right. PVH-mode VMs can't do PCI-passthrough.
You need to set it to hvm instead:
[user@dom0 ~]$ qvm-prefs some-vm virt_mode hvm
To set it back to default (pvh):
[user@dom0 ~]$ qvm-prefs -D some-vm virt_mode
I'd probably create a new VM for this testing purpose, but it's not strictly necessary.
|
Right. PVH-mode VMs can't do PCI-passthrough. You need to set it to hvm instead: To set it back to default (pvh): I'd probably create a new VM for this testing purpose, but it's not strictly necessary. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
abis866i
Jul 1, 2018
Yes, that worked. Here is what I did:
- created new appvm based on fedora, called "temp"
- changed the virtualization mode to hvm for "temp"
- attached the whole PCI card to the "temp" appvm
- ran "cheese" in "temp" and camera worked this time.
What do you advise I do, change the virtualization mode to my AppVMs to make it work?
Thank you!
abis866i
commented
Jul 1, 2018
•
edited
Edited 3 times
-
abis866i
edited Jul 1, 2018 (most recent)
-
abis866i
edited Jul 1, 2018
-
abis866i
edited Jul 1, 2018
-
abis866i
created Jul 1, 2018
edited
-
Jul 1, 2018 (most recent) -
Jul 1, 2018 -
Jul 1, 2018 -
Jul 1, 2018
|
Yes, that worked. Here is what I did:
What do you advise I do, change the virtualization mode to my AppVMs to make it work? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
jpouellet
Jul 1, 2018
Contributor
So far this only confirms the problem is with qubes' USB passthrough layer or dependencies / configuration in the templates you were using before, and rules out your camera app, USB controller itself, etc.
Now, what happens if you make another VM based on the same template as temp (qvm-clone temp temp-client should do fine) and try to use qvm-usb to pass it from temp to temp-client, and use the same "cheese" app in temp-client (which we just confirmed working in temp)?
Additionally, I believe it should be by default in fedora templates, but confirm you have qubes-usb-proxy available in temp (meaning, installed in its template). Something like:
[user@temp ~]$ sudo dnf list installed | grep qubes-usb-proxy
qubes-usb-proxy.noarch 1.0.18-1.fc26 @qubes-vm-r4.0-current
|
So far this only confirms the problem is with qubes' USB passthrough layer or dependencies / configuration in the templates you were using before, and rules out your camera app, USB controller itself, etc. Now, what happens if you make another VM based on the same template as temp ( Additionally, I believe it should be by default in fedora templates, but confirm you have |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
abis866i
Jul 1, 2018
-
Yes, I was able to use the cheese with the "temp" AppVM if the virtualization was "hvm"
-
Here is my "qubes-usb-proxy". I have noticed that your output says "fc26" while mine is "fc25". Currently, I have Fedora 28 template installed.
[user@dom0 ~]$ sudo dnf list installed | grep qubes-usb-proxy
qubes-usb-proxy-dom0.noarch 1.0.18-1.fc25 @qubes-dom0-cached
- Cloning went OK. Virtualization method for "temp-client" is still "hvm" should I change it to "pvh"?
[user@dom0 ~]$ qvm-clone temp temp-client
temp-client: Cloning private volume
- Attach the camera from temp to temp-client:
[user@dom0 ~]$ qvm-usb
BACKEND:DEVID DESCRIPTION USED BY
temp:1-2 046d_0825_A83B6C60
[user@dom0 ~]$ qvm-usb attach temp-client temp:1-2
- In temp-client run "cheese". It did not work, result is that I get a message "no device found". Output is similar to the one in 3. of my initial post.
abis866i
commented
Jul 1, 2018
•
edited
Edited 4 times
-
abis866i
edited Jul 1, 2018 (most recent)
-
abis866i
edited Jul 1, 2018
-
abis866i
edited Jul 1, 2018
-
abis866i
edited Jul 1, 2018
-
abis866i
created Jul 1, 2018
edited
-
Jul 1, 2018 (most recent) -
Jul 1, 2018 -
Jul 1, 2018 -
Jul 1, 2018 -
Jul 1, 2018
[user@dom0 ~]$ sudo dnf list installed | grep qubes-usb-proxy
[user@dom0 ~]$ qvm-clone temp temp-client
[user@dom0 ~]$ qvm-usb
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
abis866i
Jul 1, 2018
Just a note on the post above:
I can use my camera with "cheese" in the "temp" appvm when I start the appvm. But, if I attach the camera to "temp-client", try to use it in the "temp-client" with "cheese" , and then detach it, I will not be able to use it in "temp" anymore.
abis866i
commented
Jul 1, 2018
•
edited
Edited 1 time
-
abis866i
edited Jul 1, 2018 (most recent)
-
abis866i
created Jul 1, 2018
edited
-
Jul 1, 2018 (most recent) -
Jul 1, 2018
|
Just a note on the post above: |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
jpouellet
Jul 1, 2018
Contributor
virt_mode for the VM getting the USB device passed to it does not matter. The USB traffic comes in over qrexec and gets injected to USBIP - there is no PCI device involved. virt_mode=hvm is only required for the device which actually has the USB controller PCI device assigned to it.
From everything you describe, this indeed sounds like a bug in the USB passthrough code.
As a workaround, you can use "cheese" directly in the VM which has your USB device attached. So long as the camera is the only device on that USB bus, then the security benefit from further isolating cheese and providing only that USB device is unclear.
If you are care about security implications, then making your USB vm disposable and restarting your computer[1] between uses of your USB device will eliminate persistence of attacks originating over video-conferencing software (or similar) unless they re-write firmware on your USB controller (unclear if it has any) or camera (probably has some, but would likely be equally attackable regardless of whether the USB device is passed individually or not). This is admittedly inconvenient, so evaluate for your own threat model.
[1]: restarting your whole computer (not just the VM to which the USB controller is assigned) is required to reset your USB controller unless your USB controller supports function-level-reset at the PCI level, which is rare from what I've seen
|
From everything you describe, this indeed sounds like a bug in the USB passthrough code. As a workaround, you can use "cheese" directly in the VM which has your USB device attached. So long as the camera is the only device on that USB bus, then the security benefit from further isolating cheese and providing only that USB device is unclear. If you are care about security implications, then making your USB vm disposable and restarting your computer[1] between uses of your USB device will eliminate persistence of attacks originating over video-conferencing software (or similar) unless they re-write firmware on your USB controller (unclear if it has any) or camera (probably has some, but would likely be equally attackable regardless of whether the USB device is passed individually or not). This is admittedly inconvenient, so evaluate for your own threat model. [1]: restarting your whole computer (not just the VM to which the USB controller is assigned) is required to reset your USB controller unless your USB controller supports function-level-reset at the PCI level, which is rare from what I've seen |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
jpouellet
Jul 1, 2018
Contributor
Hmm, Xeon processor? If this is a server or workstation or something, then simply buying another USB PCI card and using it exclusively for a (camera, vm) pair would be ideal from a security perspective. Additionally, if the card supports function-level-reset (I wish I knew which chipsets did...) then you wouldn't need no-strict-reset and could restarting just that USB vm would be meaningful.
|
Hmm, Xeon processor? If this is a server or workstation or something, then simply buying another USB PCI card and using it exclusively for a (camera, vm) pair would be ideal from a security perspective. Additionally, if the card supports function-level-reset (I wish I knew which chipsets did...) then you wouldn't need |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
abis866i
Jul 1, 2018
Not sure if I actually have have a security model in mind. But I am fascinated by the fact that I can take resources and temporarily assign them to different vms. For example, I use Google Hangouts only for work, so in that case I would assign the camera to the "work" vm for that. For conversations with family/friends, I use Wire, so I would attach it to the personal.
abis866i
commented
Jul 1, 2018
|
Not sure if I actually have have a security model in mind. But I am fascinated by the fact that I can take resources and temporarily assign them to different vms. For example, I use Google Hangouts only for work, so in that case I would assign the camera to the "work" vm for that. For conversations with family/friends, I use Wire, so I would attach it to the personal. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
jpouellet
Jul 1, 2018
Contributor
Sure... but depending on your threat model, that can only go so far.
If you're worried about any of the video conferencing applications getting owned and the attacker persisting to webcam firmware, then you're probably still screwed.
See, e.g.:
- paper: https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-brocker.pdf
- talk: https://www.usenix.org/node/184422
- other paper: https://courses.csail.mit.edu/6.857/2014/files/03-jayaram-lui-nguyen-zakarian-preventing-covert-webcam-hacking
There's a place for separate hardware too.
|
Sure... but depending on your threat model, that can only go so far. If you're worried about any of the video conferencing applications getting owned and the attacker persisting to webcam firmware, then you're probably still screwed. See, e.g.:
There's a place for separate hardware too. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
jpouellet
Jul 1, 2018
Contributor
That's also an argument for some higher-level unidirectional-video-stream-only implementation within Qubes. Maybe one day...
|
That's also an argument for some higher-level unidirectional-video-stream-only implementation within Qubes. Maybe one day... |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
abis866i
Jul 1, 2018
No server here, it is just a system I built myself from parts from MicroCenter. Here is what I have:
- Intel Core i3-6100 SkyLake 3.7 GHz LGA 1151
- MSI Z170A PC Mate LGA 1151 ATX Intel Motherboard
- Crucial Ballistix Sport LT 64GB 4 x 16GB DDR4-2400 PC4-19200 CL16 Dual Channel
I built it in preparation for Qubes OS 4.0 as the laptop I have used with 3.2 did not pass the hardware requirements. Since camera never worked on this computer, I got a PCI card to be used only with hoping I can pass it easier. As I said, I have no specific security concerns, it is just a fascination with the model.
abis866i
commented
Jul 1, 2018
•
edited
Edited 2 times
-
abis866i
edited Jul 1, 2018 (most recent)
-
abis866i
edited Jul 1, 2018
-
abis866i
created Jul 1, 2018
edited
-
Jul 1, 2018 (most recent) -
Jul 1, 2018 -
Jul 1, 2018
|
No server here, it is just a system I built myself from parts from MicroCenter. Here is what I have:
I built it in preparation for Qubes OS 4.0 as the laptop I have used with 3.2 did not pass the hardware requirements. Since camera never worked on this computer, I got a PCI card to be used only with hoping I can pass it easier. As I said, I have no specific security concerns, it is just a fascination with the model. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
jpouellet
Jul 1, 2018
Contributor
Interesting, you say it's a Core-i3 but the PCI devs show as Xeon-E3 ¯_(ツ)_/¯
Would you mind sharing output of:
lspci -vv -s 00:14.0
lspci -vv -s 02:00.0
lspci -vv -s 03:00.0
Specifically, I'm interested if the output contains FLReset for any of the devices.
|
Interesting, you say it's a Core-i3 but the PCI devs show as Xeon-E3 ¯_(ツ)_/¯ Would you mind sharing output of: Specifically, I'm interested if the output contains |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
abis866i
Jul 1, 2018
[user@dom0 ~]$ lspci -vv -s 00:14.0
00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller (rev 31) (prog-if 30 [XHCI])
Subsystem: Micro-Star International Co., Ltd. [MSI] Device 7971
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 16
Region 0: Memory at df510000 (64-bit, non-prefetchable) [size=64K]
Capabilities:
Kernel driver in use: pciback
Kernel modules: xhci_pci
[user@dom0 ~]$ lspci -vv -s 02:00.0
02:00.0 USB controller: ASMedia Technology Inc. ASM1142 USB 3.1 Host Controller (prog-if 30 [XHCI])
Subsystem: Micro-Star International Co., Ltd. [MSI] Device 7971
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at df400000 (64-bit, non-prefetchable) [size=32K]
Capabilities:
Kernel driver in use: pciback
Kernel modules: xhci_pci
[user@dom0 ~]$ lspci -vv -s 03:00.0
03:00.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 Host Controller (rev 02) (prog-if 30 [XHCI])
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 17
Region 0: Memory at df300000 (64-bit, non-prefetchable) [disabled] [size=8K]
Capabilities:
Kernel driver in use: pciback
Kernel modules: xhci_pci
abis866i
commented
Jul 1, 2018
|
[user@dom0 ~]$ lspci -vv -s 00:14.0 [user@dom0 ~]$ lspci -vv -s 02:00.0 [user@dom0 ~]$ lspci -vv -s 03:00.0 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
abis866i
Jul 1, 2018
The usb camera is attached to the 03:00.0 USB controller: Renesas Technology Corp card and it is the only USB device on the card.
abis866i
commented
Jul 1, 2018
|
The usb camera is attached to the 03:00.0 USB controller: Renesas Technology Corp card and it is the only USB device on the card. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
jpouellet
Jul 1, 2018
Contributor
Yup. Looks like all of them need no-strict-reset :(
The quest to find a recommendable USB controller continues...
|
Yup. Looks like all of them need no-strict-reset :( The quest to find a recommendable USB controller continues... |
abis866i commentedJun 25, 2018
Qubes OS version:
R4.0
Affected component(s):
USB Camera
I am not able to use my usb camera (Logitech C270)
Camera is the only usb device on a PCI card.
Steps to reproduce the behavior:
I attach the camera PCI to the "personal" VM using the Qubes Manager
Check if camera is available in Personal VM and it seems it is attached according to second line in result.
user@personal:~$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 046d:0825 Logitech, Inc. Webcam C270
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Use 'cheese' application to see if camera is working but i does not.
user@personal:~$ cheese
(cheese:2274): Gtk-WARNING **: Theme parsing error: cheese.css:7:35: The style property GtkScrollbar:min-slider-length is deprecated and shouldn't be used anymore. It will be removed in a future version
(cheese:2274): GStreamer-CRITICAL **: gst_element_message_full_with_details: assertion 'GST_IS_ELEMENT (element)' failed
** Message: cheese-application.vala:211: Error during camera setup: No device found
(cheese:2274): cheese-CRITICAL **: cheese_camera_device_get_name: assertion 'CHEESE_IS_CAMERA_DEVICE (device)' failed
(cheese:2274): GLib-CRITICAL **: g_variant_new_string: assertion 'string != NULL' failed
(cheese:2274): GLib-GIO-CRITICAL **: g_settings_schema_key_type_check: assertion 'value != NULL' failed
(cheese:2274): GLib-CRITICAL **: g_variant_get_type_string: assertion 'value != NULL' failed
(cheese:2274): GLib-GIO-CRITICAL **: g_settings_set_value: key 'camera' in 'org.gnome.Cheese' expects type 's', but a GVariant of type '(null)' was given
** (cheese:2274): CRITICAL **: cheese_preferences_dialog_setup_resolutions_for_device: assertion 'device != NULL' failed
Check again if camera is available in Personal VM and it seems it is not attached anymore.
user@personal:~$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Expected behavior:
I would like to use my camera with Wire, Google Hangouts and eventually Skype.
Actual behavior:
Wire says there is no camera installed.
General notes:
I have tried to find an answer to this online but, unfortunately, I could not. It is probably that I am doing something wrong but I do not know how to fix this.
Related issues:
NA