mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2024-12-29 09:16:22 -05:00
fixed typos
This commit is contained in:
parent
8f7fb84a1f
commit
f4fa25d6bf
@ -49,7 +49,7 @@ If several different block-devices are attached to a single VM, the last letter
|
||||
|
||||
To specify this device node name, you can pass `--option frontend-dev=[custom-node-name]` to `qvm-block attach`.
|
||||
|
||||
#Commandline Tool Guide
|
||||
#Command Line Tool Guide
|
||||
The command-line tool you may use to mount whole USB drives or their partitions is `qvm-block`, a shortcut for `qvm-device block`.
|
||||
|
||||
`qvm-block` only sees device-nodes and may not use names you expect! So make sure to have the drive available in the sourceVM before listing available block devices (step 1.) to find out it's its ID.
|
||||
@ -108,7 +108,7 @@ To attach a file as block device to another qube, first turn it into a loopback
|
||||
|
||||
2. If you want to use the GUI, you're done. Click the Device Manager ![device manager icon] and select the `loop0`-device to attach it to another qube.
|
||||
|
||||
If you rather use the commandline, continue:
|
||||
If you rather use the command line, continue:
|
||||
|
||||
In dom0, run `qvm-block` to display known block devices. The newly created loop device should show up:
|
||||
|
||||
@ -125,7 +125,7 @@ To attach a file as block device to another qube, first turn it into a loopback
|
||||
sudo losetup -d /dev/loop0
|
||||
|
||||
#Additional Attach Options
|
||||
Attaching a block device through the commandline offers additional customisation options, specifiable via the `--option`/`-o` option. (Yes, confusing wording, there's an [issue for that](https://github.com/QubesOS/qubes-issues/issues/4530).)
|
||||
Attaching a block device through the command line offers additional customisation options, specifiable via the `--option`/`-o` option. (Yes, confusing wording, there's an [issue for that](https://github.com/QubesOS/qubes-issues/issues/4530).)
|
||||
|
||||
##frontend-dev
|
||||
This option allows you to specify the name of the device node made available in the targetVM. This defaults to `xvdi` or, if already occupied, the first available device node name in alphabetical order. (The next one tried will be `xvdj`, then `xvdk`, and so on ...)
|
||||
|
@ -29,7 +29,7 @@ Microphones, block devices and USB devices can be attached with the GUI-tool. PC
|
||||
|
||||
|
||||
#General Qubes Device Widget Behavior And Handling
|
||||
When clicking on the tray icon (looking similar to this: ![SD card and thumbdrive][device manager icon] several device-classes seperated by lines are displayed as tooltip. Block devices are displayed on top, microphones one below and USB-devices at the bottom.
|
||||
When clicking on the tray icon (looking similar to this: ![SD card and thumbdrive][device manager icon] several device-classes separated by lines are displayed as tooltip. Block devices are displayed on top, microphones one below and USB-devices at the bottom.
|
||||
|
||||
On most laptops, integrated hardware such as cameras and fingerprint-readers are implemented as USB-devices and can be found here.
|
||||
|
||||
@ -42,7 +42,7 @@ To detach a device, click the Qubes Devices Widget icon again. Attached devices
|
||||
##Attaching a Device to Several VMs
|
||||
<!--TODO: This seems like a very bad idea, but it's possible? When would I want to do that? What are the security-implications?-->
|
||||
|
||||
#General `qvm-device` Commandline Tool Behavior
|
||||
#General `qvm-device` Command Line Tool Behavior
|
||||
All devices, including PCI-devices, may be attached from the commandline using the `qvm-device`-tools.
|
||||
|
||||
##Device Classes
|
||||
@ -62,14 +62,14 @@ All devices, including PCI-devices, may be attached from the commandline using t
|
||||
|
||||
|
||||
##Global Options
|
||||
These three options are allways available:
|
||||
These three options are always available:
|
||||
|
||||
- `--help`, `-h` - show help message and exit
|
||||
- `--verbose`, `-v` - increase verbosity
|
||||
- `--quiet`, `-q` - decrease verbosity
|
||||
|
||||
|
||||
A full command consits of one DEVICE_CLASS and one action. If no action is given, list is implied. DEVICE_CLASS however is required.
|
||||
A full command consists of one DEVICE_CLASS and one action. If no action is given, list is implied. DEVICE_CLASS however is required.
|
||||
|
||||
**SYNOPSIS**:
|
||||
`qvm-device DEVICE_CLASS {action} [action-specific arguments] [options]`
|
||||
@ -100,7 +100,7 @@ The `attach` action assigns an exposed device to a VM. This makes the device ava
|
||||
`qvm-device DEVICE_CLASS {attach|at|a} targetVM sourceVM:deviceID [options]`
|
||||
|
||||
###Detaching Devices
|
||||
The `detach` action removes an assigned device from a targetVM. It won't be available afterwards anymore. Though it tries to do so gracefully, beware that data-connections might be broken unexpectedly, so close any transaction before deatching a device!
|
||||
The `detach` action removes an assigned device from a targetVM. It won't be available afterwards anymore. Though it tries to do so gracefully, beware that data-connections might be broken unexpectedly, so close any transaction before detaching a device!
|
||||
|
||||
`detach` accepts no options.
|
||||
|
||||
|
@ -16,7 +16,7 @@ You may end up with an unusable system by attaching the wrong PCI device to a VM
|
||||
|
||||
**Security warning:** PCI passthrough should be safe by default, but none-default options may be required. Please make sure you carefully read and understood the **[security considerations]** before deviating from default behavior!
|
||||
|
||||
Unlike other devices ([USB], [block], mic), PCI devices need to be attached on VM-bootup. Similar to how you can't attach a new soundcard after your computer booted (and expect it to work properly), attaching PCI devices to already booted VMs isn't possible in any meaningful way.
|
||||
Unlike other devices ([USB], [block], mic), PCI devices need to be attached on VM-bootup. Similar to how you can't attach a new sound-card after your computer booted (and expect it to work properly), attaching PCI devices to already booted VMs isn't possible in any meaningful way.
|
||||
|
||||
The Qubes installer attaches all network class controllers to `sys-net` and all USB controllers to `sys-usb` by default, if you chose to create the network and USB qube during install.
|
||||
While this covers most use cases, there are some occasions when you may want to manually attach one NIC to `sys-net` and another to a custom NetVM, or have some other type of PCI controller you want to manually attach.
|
||||
@ -37,12 +37,12 @@ The qube settings for a VM offers the "Devices"-tab. There you can attach PCI-de
|
||||
|
||||
- Press Alt+F3 to open the application finder, type in the VM name, select the "![appmenu]\[VM-name\]: Qube Settings" menu entry and press enter or click "Launch"!
|
||||
- Select the VM in Qube Manager and click the settings-button or right-click the VM and select `Qube settings`.
|
||||
- Click the Domain Manager ![device manager icon], hover the VM you want to assing a device to and select "settings" in the additional menu. (only running VMs!)
|
||||
- Click the Domain Manager ![device manager icon], hover the VM you want to attach a device to and select "settings" in the additional menu. (only running VMs!)
|
||||
|
||||
2. Select the "Devices" tab on the top bar.
|
||||
3. Select a device you want to attach to the qube and click the single arrow right! (`>`)
|
||||
4. You're done. If everything worked out, once the qube boots (or reboots if it's running) it will start with the pci device attached.
|
||||
5. In case it doesn't work out, first try disabeling memory-balancing in the settings ("Advanced" tab). If that doesn't help, read on to learn how to disable the strict reset requirement!
|
||||
5. In case it doesn't work out, first try disabling memory-balancing in the settings ("Advanced" tab). If that doesn't help, read on to learn how to disable the strict reset requirement!
|
||||
|
||||
#`qvm-pci` Usage
|
||||
The `qvm-pci` tool allows PCI attachment and detachment. It's a shortcut for [`qvm-device pci`][qvm-device].
|
||||
@ -68,7 +68,7 @@ For example, if `00_1a.0` is the BDF of the device you want to attach to the "wo
|
||||
|
||||
##DMA Buffer Size
|
||||
|
||||
VMs with assigned PCI devices in Qubes have allocated a small buffer for DMA operations (called swiotlb).
|
||||
VMs with attached 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):
|
||||
|
||||
@ -86,7 +86,7 @@ There is a way to enable permissive mode for it.
|
||||
See also: [this thread][ml2] and the Xen wiki's [PCI passthrough] page.
|
||||
At other times, you may instead need to disable the FLR requirement on a device.
|
||||
|
||||
Both can be acchieved during attachment with `qvm-pci` as described below.
|
||||
Both can be achieved during attachment with `qvm-pci` as described below.
|
||||
|
||||
|
||||
#Additional Attach Options
|
||||
@ -102,7 +102,7 @@ usage example:
|
||||
qvm-pci a work dom0:00_1a.0 --persistent -o no-strict-reset=true
|
||||
|
||||
##permissive
|
||||
Allow write access to full PCI config space instead of whitlisted registers. This increases attack surface and possibility of [side channel attacks].
|
||||
Allow write access to full PCI config space instead of whitelisted registers. This increases attack surface and possibility of [side channel attacks].
|
||||
|
||||
usage example:
|
||||
|
||||
@ -115,7 +115,7 @@ By default, when a device is detached from a VM (or when a VM with an attached P
|
||||
|
||||
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.
|
||||
A device which was previously attached to a VM less trusted than dom0 (which, in Qubes, is *all* of them) could attack dom0 if it were automatically reattached there.
|
||||
|
||||
In order to re-enable the device in dom0, either:
|
||||
|
||||
|
@ -16,10 +16,10 @@ USB Devices in Qubes R4.0
|
||||
Examples for valid cases for USB-passthrough:
|
||||
|
||||
- [microcontroller programming]
|
||||
- using [extarnal audio devices]
|
||||
- using [external audio devices]
|
||||
- [optical drives] for recording
|
||||
|
||||
(If you are thinking to use a two-factor-authentification device, [there is an app for that][qubes u2f proxy]. But it has some [issues][4661].)
|
||||
(If you are thinking to use a two-factor-authentication device, [there is an app for that][qubes u2f proxy]. But it has some [issues][4661].)
|
||||
|
||||
#Attaching And Detaching a USB Device
|
||||
##With Qubes Device Manager
|
||||
@ -66,10 +66,10 @@ When you finish, detach the device.
|
||||
sys-usb:2-5 058f:3822 058f_USB_2.0_Camera
|
||||
sys-usb:2-1 03f0:0641 PixArt_HP_X1200_USB_Optical_Mouse
|
||||
|
||||
#Maintainence And Customisation
|
||||
#Maintenance And Customisation
|
||||
|
||||
##Creating And Using a USB qube
|
||||
If you've selected to install a usb-qube during system installation, everything is already set up for you in `sys-usb`. If you've later decided to create a usb-qube, plese follow [this guide][USB-qube howto].
|
||||
If you've selected to install a usb-qube during system installation, everything is already set up for you in `sys-usb`. If you've later decided to create a usb-qube, please follow [this guide][USB-qube howto].
|
||||
|
||||
##Installation Of `qubes-usb-proxy`
|
||||
To use this feature, the[`qubes-usb-proxy`][qubes-usb-proxy] package needs to be installed in the templates used for the USB qube and qubes you want to connect USB devices to.
|
||||
@ -132,9 +132,9 @@ Strip the leading `0000:` and pass the rest to the [`qvm-pci` tool][qvm-pci] to
|
||||
[security considerations]: /doc/device-considerations/#usb-security
|
||||
[usb-challenges]: https://blog.invisiblethings.org/2011/05/31/usb-security-challenges.html
|
||||
[microcontroller programming]: https://www.arduino.cc/en/Main/Howto
|
||||
[extarnal audio devices]: /doc/external-audio/
|
||||
[external audio devices]: /doc/external-audio/
|
||||
[optical drives]: /doc/recording-optical-discs/
|
||||
[qubes u2f proxy]: https://www.qubes-os.org/news/2018/09/11/qubes-u2f-proxy/
|
||||
[qubes u2f proxy]: /doc/u2f-proxy/
|
||||
[4661]: https://github.com/QubesOS/qubes-issues/issues/4661
|
||||
[device manager icon]:https://raw.githubusercontent.com/hrdwrrsk/adwaita-xfce-icon-theme/master/Adwaita-Xfce/22x22/devices/media-removable.png <!--TODO: find actual icon used in qubes!-->
|
||||
[eject icon]:https://raw.githubusercontent.com/hrdwrrsk/adwaita-xfce-icon-theme/master/Adwaita-Xfce/22x22/actions/media-eject.png
|
||||
|
@ -26,7 +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.
|
||||
|
||||
Using the Commandline
|
||||
Using the Command Line
|
||||
------------------------
|
||||
|
||||
In order to assign a whole PCI(e) device to a VM, one should use the `qvm-pci` tool.
|
||||
@ -64,7 +64,7 @@ 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]!
|
||||
Please refer 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!
|
||||
|
||||
Enabling permissive mode
|
||||
|
@ -6,9 +6,9 @@ permalink: /doc/usb-qube-how-to/
|
||||
|
||||
USB Qube HowTo
|
||||
==============
|
||||
If during installation you enabled the creation of a USB-qube, your system should be setup already and none of the mentioned steps here should be necessarry. (Unless you want to [remove your USB-qube].) If for any reason no USB-qube was created during installation, this guide will show you how to do so.
|
||||
If during installation you enabled the creation of a USB-qube, your system should be setup already and none of the mentioned steps here should be necessary. (Unless you want to [remove your USB-qube].) If for any reason no USB-qube was created during installation, this guide will show you how to do so.
|
||||
|
||||
**Caution:** If you want to use a USB-keyboard, please beware of the possiblity to lock yourself out! To avoid this problem [enable your keyboard for login]!
|
||||
**Caution:** If you want to use a USB-keyboard, please beware of the possibility to lock yourself out! To avoid this problem [enable your keyboard for login]!
|
||||
|
||||
Creating and Using a USB qube
|
||||
-----------------------------
|
||||
|
@ -19,9 +19,9 @@ PCI Security
|
||||
------------
|
||||
Attaching a PCI device to a qube gives it full control of that device and is vulnerable to any bug or malicious implementation of the hardware, as well as plain security problems the hardware may pose. (For example, if you attach a USB controller, all the security implications of USB passthrough apply as well.)
|
||||
|
||||
By default, Qubes requires any PCI device to be resettable from the outside (i.e. via the hyperviser), which completely reinitialises the device. This ensures that any device that was attached to a compromised VM, even if that VM was able to use bugs in the PCI device to inject malicious code, can be trusted again. (Or at least as trusted as it was when Qubes booted.)
|
||||
By default, Qubes requires any PCI device to be resettable from the outside (i.e. via the hypervisor), which completely reinitialises the device. This ensures that any device that was attached to a compromised VM, even if that VM was able to use bugs in the PCI device to inject malicious code, can be trusted again. (Or at least as trusted as it was when Qubes booted.)
|
||||
|
||||
Some devices do not implement a reset option. In these cases, Qubes by default does not allow attaching the device to any VM. If you decide to override this precausion, beware that the device may only be trusted when attached to the first VM. Afterwards, it should be **considered tainted** until the whole system is shut down. Even without malicious intent, uage data may be leaked.
|
||||
Some devices do not implement a reset option. In these cases, Qubes by default does not allow attaching the device to any VM. If you decide to override this precaution, beware that the device may only be trusted when attached to the first VM. Afterwards, it should be **considered tainted** until the whole system is shut down. Even without malicious intent, usage data may be leaked.
|
||||
|
||||
Additionally, Qubes restricts the config-space a VM may use to communicate with a PCI device. Only whitelisted registers are accessible. However, some devices or applications require full PCI access. In these cases, the whole config-space may be allowed. you're potentially weakening the device isolation, especially if your system is not equipped with a VT-d Interrupt Remapping unit. This increases the VM's ability to run a [side channel attack] and vulnerability to the same. <!--TODO: really? It seems obvious, but I'm missing citation.-->
|
||||
See [Software Attacks on Intel VT-d] (page 7) for more details.
|
||||
|
Loading…
Reference in New Issue
Block a user