Some devices do not implement a reset option. (Or at least as trusted as it was when Qubes booted.) 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. via the hypervisor), which completely reinitialises the device. (For example, if you attach a USB controller, all the security implications of USB passthrough apply as well.)īy default, Qubes requires any PCI device to be resettable from the outside (i.e. In many cases a malicious device can choose what driver will be loaded (for example by manipulating device metadata like vendor and product identifiers) - even if the intended driver is sufficiently secure, the device may try to attack a different, less secure driver.įurthermore that VM has full control of the device and may be able to exploit bugs or malicious implementation of the hardware, as well as plain security problems the hardware may pose. It exposes the device driver running in the qube to an external device (and sourceVM, which contains the device - e.g. (Attaching a full block device offers the advantage that most file-managers will mount and display them correctly, whereas they don’t expect single partitions to be added and therefore don’t handle them correctly.) PCI SecurityĪttaching a PCI device to a qube has serious security implications. sda1), since the targetVM doesn’t have to parse the partition-table. sda) again offers more attack surface than attaching a single partition (e.g. It’s a good idea to always attach the minimum entity required in a VM.įor example, attaching a full USB-device offers more attack surface than attaching a single block device, whileĪttaching a full block device (e.g.

Any additional ability a VM gains is additional attack surface.

Usb security full