Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2024-12-27 00:09:26 -05:00
Code Issues Packages Projects Releases Wiki Activity

Removed documentation from deprecated pages

Browse Source
This commit is contained in:
GammaSQ 2019-01-05 11:21:30 +01:00
parent 30e58b17b5
commit 706498d976
No known key found for this signature in database
GPG Key ID: D552FD2F98647C64
2 changed files with 26 additions and 476 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

343
common-tasks/usb.md
View File

@ -1,6 +1,6 @@
---
layout: doc
title: Using and Managing USB Devices
title: Using and Managing USB Devices in R3.2
permalink: /doc/usb/
redirect_from:
- /doc/stick-mounting/
@ -18,82 +18,18 @@ redirect_from:
- /doc/sys-usb/
---
Using and Managing USB Devices
==============================
Using and Managing USB Devices in R3.2
======================================
(In case you were looking for the [R4.0 documentation](/doc/usb-devices/).)
How to attach USB drives
----------
------------------------
(**Note:** In the present context, the term "USB drive" denotes any [USB mass storage device][mass-storage].
In addition to smaller flash memory sticks, this includes things like USB external hard drives.)
Qubes OS supports the ability to attach a USB drive (or just one or more of its partitions) to any qube easily, no matter which qube actually handles the USB controller.
### R4.0 ###
USB drive mounting is integrated into the Devices Widget.
This is the tool tray icon with a yellow square located in the top right of your screen by default.
Simply insert your USB drive and click on the widget.
You will see multiple entries for your USB drive; typically, `sys-usb:sda`, `sys-usb:sda1`, and `sys-usb:2-1` for example.
The simplest (but slightly less secure, see note below about attaching individual partitions) option is to attach the entire block drive.
In our example, this is `sda`, so hover over it.
This will pop up a submenu showing running VMs to which the USB drive can be connected.
Click on one and your USB drive will be attached!
Note that attaching individual partitions can be slightly more secure because it doesn't force the target AppVM to parse the partition table.
However, it often means the AppVM won't detect the new partition and you will need to manually mount it inside the AppVM.
See below for more detailed steps.
The command-line tool you may use to mount whole USB drives or their partitions is `qvm-block`.
This tool can be used to assign a USB drive to a qube as follows:
1. Insert your USB drive.
2. In a dom0 console (running as a normal user), list all available block devices:
qvm-block
This will list all available block devices connected to any USB controller in your system, no matter which qube hosts the controller.
The name of the qube hosting the USB controller is displayed before the colon in the device name.
The string after the colon is the name of the device used within the qube, like so:
dom0:sdb1 Cruzer () 4GiB
usbVM:sdb1 Disk () 2GiB
**Note:** If your device is not listed here, you may refresh the list by calling from the qube to which the device is connected (typically `sys-usb`):
sudo udevadm trigger --action=change
3. Assuming your USB drive is attached to `sys-usb` and is `sdb`, we attach the device to a qube with the name `personal` like so:
qvm-block attach personal sys-usb:sdb
This will attach the device to the qube as `/dev/xvdi` if that name is not already taken by another attached device, or `/dev/xvdj`, etc.
You may also mount one partition at a time by using the same command with the partition number after `sdb`.
4. The USB drive is now attached to the qube.
If using a default qube, you may open the Nautilus file manager in the qube, and your drive should be visible in the **Devices** panel on the left.
If you've attached a single partition, you may need to manually mount before it becomes visible:
```
cd ~
mkdir mnt
sudo mount /dev/xvdi mnt
```
5. When you finish using your USB drive, click the eject button or right-click and select **Unmount**.
If you've manually mounted a single partition in the above step, use:
`sudo umount mnt`
6. In a dom0 console, detach the stick
qvm-block detach <vmname> <device>
7. You may now remove the device.
### R3.2 ###
USB drive mounting is integrated into the Qubes VM Manager GUI.
Simply insert your USB drive, right-click on the desired qube in the Qubes VM Manager list, click **Attach/detach block devices**, and select your desired action and device.
However, this only works for the whole device.
@ -170,7 +106,7 @@ If the device does not appear in Nautilus, you will need to mount it manually.
The device will show up as `/dev/xvdi` (or `/dev/xvdj` if there is already one device attached -- if two, `/dev/xvdk`, and so on).
### What if I removed the device before detaching it from the VM? (R3.2) ###
### What if I removed the device before detaching it from the VM?###
Currently (until issue [1082] gets implemented), if you remove the device before detaching it from the qube, Qubes OS (more precisely, `libvirtd`) will think that the device is still attached to the qube and will not allow attaching further devices under the same name.
The easiest way to recover from such a situation is to reboot the qube to which the device was attached.
@ -216,52 +152,7 @@ However, if you receive this error: `ERROR: qubes-usb-proxy not installed in the
- Fedora: `sudo dnf install qubes-usb-proxy`
- Debian/Ubuntu: `sudo apt-get install qubes-usb-proxy`
### Usage of qubes-usb-proxy (R4.0) ###
This feature is also available from the Devices Widget.
This is the tool tray icon with a yellow square located in the top right of your screen by default.
Simply insert your USB device and click on the widget.
You will see an entry for your device such as `sys-usb:2-5 - 058f_USB_2.0_Camera` for example.
Hover over it.
This will pop up a submenu showing running VMs to which the USB device can be connected.
Click on one and your device will be attached!
You may also use the command line:
Listing available USB devices:
[user@dom0 ~]$ qvm-usb
sys-usb:2-4 04ca:300d 04ca_300d
sys-usb:2-5 058f:3822 058f_USB_2.0_Camera
sys-usb:2-1 03f0:0641 PixArt_HP_X1200_USB_Optical_Mouse
Attaching selected USB device:
[user@dom0 ~]$ qvm-usb attach conferences sys-usb:2-5
[user@dom0 ~]$ qvm-usb
conferences:2-1 058f:3822 058f_USB_2.0_Camera
sys-usb:2-4 04ca:300d 04ca_300d
sys-usb:2-5 058f:3822 058f_USB_2.0_Camera (attached to conferences)
sys-usb:2-1 03f0:0641 PixArt_HP_X1200_USB_Optical_Mouse
Now, you can use your USB device (camera in this case) in the `conferences` qube.
If you see the error `ERROR: qubes-usb-proxy not installed in the VM` instead, please refer to the [Installation Section][installation].
When you finish, detach the device.
This can be done in the GUI by clicking on the Devices Widget.
You will see an entry in bold for your device such as **`sys-usb:2-5 - 058f_USB_2.0_Camera`**.
Hover over it.
This will pop up a submenu showing running VMs.
The one to which your device is connected will have an Eject button next to it.
Click that and your device will be detached.
You may also use the command line:
[user@dom0 ~]$ qvm-usb detach conferences sys-usb:2-5
[user@dom0 ~]$ qvm-usb
sys-usb:2-4 04ca:300d 04ca_300d
sys-usb:2-5 058f:3822 058f_USB_2.0_Camera
sys-usb:2-1 03f0:0641 PixArt_HP_X1200_USB_Optical_Mouse
### Usage of qubes-usb-proxy (R3.2) ###
### Usage of qubes-usb-proxy ###
Listing available USB devices:
@ -292,226 +183,16 @@ When you finish, detach the device:
This feature is not available in Qubes Manager.
Creating and Using a USB qube
-----------------------------
**Warning:** This has the potential to prevent you from connecting a keyboard to Qubes via USB.
There are problems with doing this in an encrypted install (LUKS).
If you find yourself in this situation, see this [issue][2270-comm23].
The connection of an untrusted USB device to dom0 is a security risk since dom0, like almost every OS, reads partition tables automatically.
The whole USB stack is put to work to parse the data presented by the USB device in order to determine if it is a USB mass storage device, to read its configuration, etc.
This happens even if the drive is then assigned and mounted in another qube.
To avoid this risk, it is possible to prepare and utilize a USB qube.
A USB qube acts as a secure handler for potentially malicious USB devices, preventing them from coming into contact with dom0 (which could otherwise be fatal to the security of the whole system).
With a USB qube, every time you connect an untrusted USB drive to a USB port managed by that USB controller, you will have to attach it to the qube in which you wish to use it (if different from the USB qube itself), either by using Qubes VM Manager or the command line (see instructions above).
The USB controller may be assigned on the **Devices** tab of a qube's settings page in Qubes VM Manager or by using the [qvm-pci][Assigning Devices] command.
For guidance on finding the correct USB controller, see [here][usb-controller].
You can create a USB qube using the management stack by performing the following steps as root in dom0:
sudo qubesctl state.sls qvm.sys-usb
Alternatively, you can create a USB qube manually as follows:
1. Read the [Assigning Devices] page to learn how to list and identify your USB controllers.
Carefully check whether you have a USB controller that would be appropriate to assign to a USB qube.
Note that it should be free of input devices, programmable devices, and any other devices that must be directly available to dom0.
If you find a free controller, note its name and proceed to step 2.
2. Create a new qube.
Give it an appropriate name and color label (recommended: `sys-usb`, red).
If you need to attach a networking device, it might make sense to create a NetVM.
If not, an AppVM might make more sense.
(The default `sys-usb` is a NetVM.)
3. In the qube's settings, go to the "Devices" tab.
Find the USB controller that you identified in step 1 in the "Available" list.
Move it to the "Selected" list.
**Caution:** By assigning a USB controller to a USB qube, it will no longer be available to dom0.
This can make your system unusable if, for example, you have only one USB controller, and you are running Qubes off of a USB drive.
4. Click `OK`.
Restart the qube.
5. Recommended: Check the box on the "Basic" tab which says "Start VM automatically on boot".
(This will help to mitigate attacks in which someone forces your system to reboot, then plugs in a malicious USB device.)
If the USB qube will not start, see [here][faq-usbvm].
How to hide all USB controllers from dom0
-----------------------------------------
If you create a USB qube manually, there will be a brief period of time during the boot process when dom0 will be exposed to your USB controllers (and any attached devices).
This is a potential security risk, since even brief exposure to a malicious USB device could result in dom0 being compromised.
There are two approaches to this problem:
1. Physically disconnect all USB devices whenever you reboot the host.
2. Hide (i.e., blacklist) all USB controllers from dom0.
**Warning:** If you use a USB [AEM] device, do not use the second option.
Using a USB AEM device requires dom0 to have access to the USB controller to which your USB AEM device is attached.
If dom0 cannot read your USB AEM device, AEM will hang.
The procedure to hide all USB controllers from dom0 is as follows:
* GRUB2
1. Open the file `/etc/default/grub` in dom0.
2. Find the line that begins with `GRUB_CMDLINE_LINUX`.
3. Add `rd.qubes.hide_all_usb` to that line.
4. Save and close the file.
5. Run the command `grub2-mkconfig -o /boot/grub2/grub.cfg` in dom0.
6. Reboot.
* EFI
1. Open the file `/boot/efi/EFI/qubes/xen.cfg` in dom0.
2. Find the lines that begin with `kernel=`. There may be more than one.
3. Add `rd.qubes.hide_all_usb` to those lines.
4. Save and close the file.
5. Reboot.
(Note: Beginning with R3.2, `rd.qubes.hide_all_usb` is set automatically if you opt to create a USB qube during installation.
This also occurs automatically if you choose to [create a USB qube] using the `qubesctl` method, which is the
first pair of steps in the linked section.)
**Warning:** A USB keyboard cannot be used to type the disk passphrase if USB controllers were hidden from dom0.
Before hiding USB controllers, make sure your laptop keyboard is not internally connected via USB (by checking output of the `lsusb` command) or that you have a PS/2 keyboard at hand (if using a desktop PC).
Failure to do so will render your system unusable.
Removing a USB qube
Additional Reading:
-------------------
**Warning:** This procedure will result in your USB controller(s) being attached directly to dom0.
* GRUB2
1. Shut down the USB qube.
2. In Qubes Manager, right-click on the USB qube and select "Remove VM."
3. Open the file `/etc/default/grub` in dom0.
4. Find the line(s) that begins with `GRUB_CMDLINE_LINUX`.
5. If `rd.qubes.hide_all_usb` appears anywhere in those lines, remove it.
6. Save and close the file.
7. Run the command `grub2-mkconfig -o /boot/grub2/grub.cfg` in dom0.
8. Reboot.
* EFI
1. Shut down the USB qube.
2. In Qubes Manager, right-click on the USB qube and select "Remove VM."
3. Open the file `/boot/efi/EFI/qubes/xen.cfg` in dom0.
4. Find the line(s) that begins with `kernel=`.
5. If `rd.qubes.hide_all_usb` appears anywhere in those lines, remove it.
6. Save and close the file.
7. Reboot.
Security Warning about USB Input Devices
----------------------------------------
**Important security warning. Please read this section carefully!**
If you connect USB input devices (keyboard and mouse) to a VM, that VM will effectively have control over your system.
Because of this, the benefits of using a USB qube are much smaller than using a fully untrusted USB qube.
In addition to having control over your system, such a VM can also sniff all the input you enter there (for example, passwords in the case of a USB keyboard).
There is no simple way to protect against sniffing, but you can make it harder to exploit control over input devices.
If you have only a USB mouse connected to a USB qube, but the keyboard is connected directly to dom0 (using a PS/2 connector, for example), you simply need to lock the screen when you are away from your computer.
You must do this every time you leave your computer unattended, even if there no risk of anyone else having direct physical access to your computer.
This is because you are guarding the system not only against anyone with local access, but also against possible actions from a potentially compromised USB qube.
If your keyboard is also connected to a USB qube, things are much harder.
Locking the screen (with a traditional password) does not solve the problem, because the USB qube can simply sniff this password and later easily unlock the screen.
One possibility is to set up the screen locker to require an additional step to unlock (i.e., two-factor authentication).
One way to achieve this is to use a [YubiKey], or some other hardware token, or even to manually enter a one-time password.
How to use a USB keyboard
-------------------------
**Caution:** Please carefully read the [Security Warning about USB Input Devices] before proceeding.
If you use USB keyboard, automatic USB qube creation during installation is disabled.
Additional steps are required to avoid locking you out from the system.
Those steps are not performed by default, because of risk explained in [Security Warning about USB Input Devices].
### R4.0, using salt ###
To allow USB keyboard usage (including early boot for LUKS passphrase), make sure you have the latest `qubes-mgmt-salt-dom0-virtual-machines` package (simply [install dom0 updates][dom0-updates]) and execute in dom0:
sudo qubesctl state.sls qvm.usb-keyboard
The above command will take care of all required configuration, including creating USB qube if not present.
Note that it will expose dom0 to USB devices while entering LUKS passphrase.
Users are advised to physically disconnect other devices from the system for that time, to minimize the risk.
If you wish to perform only subset of this configuration (for example do not enable USB keyboard during boot), see manual instructions below.
### R3.2, manual ###
In order to use a USB keyboard, you must first attach it to a USB qube, then give that qube permission to pass keyboard input to dom0.
Edit the `qubes.InputKeyboard` policy file in dom0, which is located here:
/etc/qubes-rpc/policy/qubes.InputKeyboard
Add a line like this one to the top of the file:
sys-usb dom0 allow,user=root
(Change `sys-usb` to your desired USB qube.)
You can now use your USB keyboard.
For a confirmation dialog each time the USB keyboard is connected, change this line to:
```
sys-usb dom0 ask,default_target=dom0
```
Additionally, if you want to use USB keyboard to enter LUKS passphrase, it is incompatible with [hiding USB controllers from dom0][How to hide all USB controllers from dom0].
You need to revert that procedure (remove `rd.qubes.hide_all_usb` option from files mentioned there) and employ alternative protection during system boot - disconnect other devices during startup.
How to use a USB mouse
----------------------
**Caution:** Please carefully read the [Security Warning about USB Input Devices] before proceeding.
In order to use a USB mouse, you must first attach it to a USB qube, then give that qube permission to pass mouse input to dom0.
The following steps are already done by default if you created the sys-usb qube with `qubesctl state.sls qvm.sys-usb` above, or let Qubes create it for you on first boot.
However, if you've created the USB qube manually:
Edit the `qubes.InputMouse` policy file in dom0, which is located here:
/etc/qubes-rpc/policy/qubes.InputMouse
Add a line like this to the top of the file:
sys-usb dom0 allow,user=root
(Change `sys-usb` to your desired USB qube.)
You can now use your USB mouse.
For a confirmation dialog each time the USB mouse is connected, change this line to:
```
sys-usb dom0 ask,default_target=dom0
```
- [Creating a USB qube]
- [Using a USB keyboard]
[mass-storage]: https://en.wikipedia.org/wiki/USB_mass_storage_device_class
[Assigning Devices]: /doc/assigning-devices/
[usb-controller]: /doc/assigning-devices/#finding-the-right-usb-controller
[623]: https://github.com/QubesOS/qubes-issues/issues/623
[1072-comm1]: https://github.com/QubesOS/qubes-issues/issues/1072#issuecomment-124270051
[1072-comm2]: https://github.com/QubesOS/qubes-issues/issues/1072#issuecomment-124119309
[2270-comm23]: https://github.com/QubesOS/qubes-issues/issues/2270#issuecomment-242900312
[1082]: https://github.com/QubesOS/qubes-issues/issues/1082
[hide-usb]: #how-to-hide-all-usb-controllers-from-dom0
[faq-usbvm]: /faq/#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot
[AEM]: /doc/anti-evil-maid/
[1618]: https://github.com/QubesOS/qubes-issues/issues/1618
[create a USB qube]: #creating-and-using-a-usb-qube
[usb-challenges]: https://blog.invisiblethings.org/2011/05/31/usb-security-challenges.html
[YubiKey]: /doc/YubiKey/
[Security Warning about USB Input Devices]: #security-warning-about-usb-input-devices
[How to hide all USB controllers from dom0]: #how-to-hide-all-usb-controllers-from-dom0
[qubes-usb-proxy]: https://github.com/QubesOS/qubes-app-linux-usb-proxy
[dom0-updates]: /doc/software-update-dom0/#how-to-update-software-in-dom0
[Creating a USB qube]: /doc/usb-qube-how-to/
[Using a USB keyboard]: /doc/usb-qube-how-to/#enable-a-usb-keyboard-for-login

159
configuration/assigning-devices.md
View File

@ -1,6 +1,6 @@
---
layout: doc
title: Assigning Devices
title: Assigning Devices in R3.2
permalink: /doc/assigning-devices/
redirect_from:
- /en/doc/assigning-devices/
@ -8,8 +8,9 @@ redirect_from:
- /wiki/AssigningDevices/
---
Assigning Devices to VMs
========================
Assigning Devices to VMs in R3.2
================================
(In case you were looking for the [R4.0 documentation](/doc/pci-devices/).)
Sometimes you may need to assign an entire PCI or PCI Express device directly to a qube.
This is also known as PCI pass-through.
@ -25,31 +26,7 @@ While PCI device can only be used by one powered on VM at a time, it *is* possib
This means that you can use the device in one VM, shut that VM down, start up a different VM (to which the same device is also assigned), then use the device in that VM.
This can be useful if, for example, you have only one USB controller, but you have multiple security domains which all require the use of different USB devices.
R4.0
------------------------
In order to assign a whole PCI(e) device to a VM, one should use the `qvm-pci` tool.
First, list the available PCI devices:
~~~
qvm-pci
~~~
This will show you the `backend:BDF` address of each PCI device.
It will look something like `dom0:00_1a.0`.
Once you've found the address of the device you want to assign, then attach it like so:
~~~
qvm-pci attach --persistent <vmname> <backend>:<bdf>
~~~
For example, if `00_1a.0` is the BDF of the device you want to assign to the "personal" domain, you would do this:
~~~
qvm-pci attach --persistent personal dom0:00_1a.0
~~~
R3.2
Using the Commandline
------------------------
In order to assign a whole PCI(e) device to a VM, one should use the `qvm-pci` tool.
@ -83,103 +60,14 @@ This will show you a list of available devices, which you can select to be assig
Finding the right USB controller
--------------------------------
Some USB devices are not compatible with the USB pass-through method Qubes employs.
In situations like this, you can still often get the USB device to work by passing through the entire USB controller to a qube.
However, with this approach one cannot assign single USB devices, only the whole USB controller with whatever USB devices are connected to it.
More information on using and managing USB devices with qubes is available on the [USB] page.
If you want assign a certain USB device to a VM by attaching the whole USB controller, you need to figure out which PCI device is the right controller.
First, check to which USB bus the device is connected (note that these steps need to be run from a terminal inside `dom0`):
~~~
lsusb
~~~
For example, I want assign a broadband modem to the NetVM.
In the output of `lsusb` it can be listed as something like this.
(In this case, the device isn't fully identified):
~~~
Bus 003 Device 003: ID 413c:818d Dell Computer Corp.
~~~
The device is connected to USB bus \#3.
Then check which other devices are connected to the same bus, since *all* of them will be assigned to the same VM.
Now is the time to find the right USB controller:
~~~
readlink /sys/bus/usb/devices/usb3
~~~
This should output something like:
~~~
../../../devices/pci-0/pci0000:00/0000:00:1a.0/usb3
~~~
Now you see the BDF address in the path (right before final `usb3`).
Strip the leading `0000:` and pass the rest to the `qvm-pci` tool to attach the controller with the version specific steps above.
This was moved to the [current documentation][finding controller].
Possible issues
---------------
Please refere to the [current documentation][possible issues] for an issue description and carefully read the [security implications]!
Return here for a guide on how to enable permissive mode and disable strict reset!
### DMA buffer size
VMs with assigned PCI devices in Qubes have allocated a small buffer for DMA operations (called swiotlb).
By default it is 2MB, but some devices need a larger buffer.
To change this allocation, edit VM's kernel parameters (this is expressed in 512B chunks):
~~~
# qvm-prefs netvm |grep kernelopts
kernelopts : iommu=soft swiotlb=2048 (default)
# qvm-prefs -s netvm kernelopts "iommu=soft swiotlb=8192"
~~~
This is [known to be needed][ml1] for the Realtek RTL8111DL Gigabit Ethernet Controller.
### PCI passthrough issues
Sometimes the PCI arbitrator is too strict.
There is a way to enable permissive mode for it.
See also: [this thread][ml2] and the Xen wiki's [PCI passthrough] page.
**NOTE:** By setting the permissive flag for the PCI device, you're potentially weakening the device isolation, especially if your system is not equipped with a VT-d Interrupt Remapping unit.
See [Software Attacks on Intel VT-d] (page 7)
for more details.
At other times, you may instead need to disable the FLR requirement on a device.
This will also weaken device isolation; see the "I created a usbVM..." entry in the [FAQ](/doc/user-faq/) for more details.
R4.0
------------------------
Permissive mode and strict reset are options set as part of PCI device attachment.
If you've already attached the PCI device to a VM, detach it first either with Qube Manager or `qvm-pci`, then list the available PCI devices:
~~~
qvm-pci
~~~
This will show you the `backend:BDF` address of each PCI device.
It will look something like `dom0:00_1a.0`.
Once you've found the address of the device you want to assign, then attach it like so:
~~~
qvm-pci attach --persistent --option <option1> [--option <option2>] <vmname> <backend>:<bdf>
~~~
For example, if `00_1a.0` is the BDF of the device you want to assign to the "personal" domain, and it is particularly difficult to pass through you would do this:
~~~
qvm-pci attach --persistent --option permissive=true --option no-strict-reset=true personal dom0:00_1a.0
~~~
Running `qvm-pci` again should then show your PCI device attached with both the `permissive` and `no-strict-reset` options set.
**Note** again that in most cases you should not need either of these options set.
Only set one or more of them as required to get your device to function, or replace the device with one that functions properly with Qubes.
R3.2
Enabling permissive mode
------------------------
Permissive mode is enabled system wide per device.
@ -213,31 +101,12 @@ Only set one or more of them as required to get your device to function, or repl
Bringing PCI device back to dom0
--------------------------------
This was moved to the [current documentation][bring back devices].
By default, when a device is detached from a VM (or when a VM with an attached PCI device is shut down), the device is *not* automatically attached back to dom0.
This is an intended feature.
A device which was previously assigned to a VM less trusted than dom0 (which, in Qubes, is *all* of them) could attack dom0 if it were automatically reassigned there.
In order to re-enable the device in dom0, either:
* Reboot the physical machine.
or
* Go to the sysfs (`/sys/bus/pci`), find the right device, detach it from the pciback driver, and attach it back to the original driver.
Replace `<BDF>` with your full device, for example `0000:00:1c.2`:
~~~
echo <BDF> > /sys/bus/pci/drivers/pciback/unbind
MODALIAS=`cat /sys/bus/pci/devices/<BDF>/modalias`
MOD=`modprobe -R $MODALIAS | head -n 1`
echo <BDF> > /sys/bus/pci/drivers/$MOD/bind
~~~
[usb]: /doc/usb/
[ml1]: https://groups.google.com/group/qubes-devel/browse_thread/thread/631c4a3a9d1186e3
[ml2]: https://groups.google.com/forum/#!topic/qubes-users/Fs94QAc3vQI
[PCI passthrough]: https://wiki.xen.org/wiki/Xen_PCI_Passthrough
[Software Attacks on Intel VT-d]: https://invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf
[finding controller]: /doc/usb-devices/#finding-the-right-usb-controller
[possible issues]: /doc/pci-devices/#possible-issues
[security implications]: /doc/device-considerations/#pci-security
[bring back devices]: /doc/pci-devices/#bringing-pci-devices-back-to-dom0