q-dev: avoid zombie USB device

[piotrbartman]

After detaching from the frontend VM, the USB device remained under the control of the usbip driver. This caused the device to remain visible in the backend vm but unusable there (zombie). The issue is that, for example, a USB stick would not expose its partitions to the backend, preventing us from using them (e.g. attaching partition to frontend vm).

[qubesos-bot]

OpenQA test summary

Complete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2026062019-devel&flavor=pull-requests

Test run included the following:

• q-dev: avoid zombie USB device #55 (74a059a)
• Add Arch packaging qubes-core-admin-client#332 (QubesOS/qubes-core-admin-client@71b1e21)
• tests: log more info on failure qubes-core-admin#736 (QubesOS/qubes-core-admin@a3fc21c)
• DONOTMERGE - Enable qmemman debug log qubes-core-admin#783 (QubesOS/qubes-core-admin@d986e13)
• Disable notification for denied property.GetAll call qubes-core-admin#830 (QubesOS/qubes-core-admin@e0fe88d)
• Log calls made from dom0 to the journal qubes-core-qrexec#232 (QubesOS/qubes-core-qrexec@e126a43)
• Schedule synchronous function to separate thread qubes-desktop-linux-manager#312 (QubesOS/qubes-desktop-linux-manager@ad0f5e3)
• Disable forced DPI to fix font kerning qubes-desktop-linux-xfce4#32 (QubesOS/qubes-desktop-linux-xfce4@7facd1d)
• Disable automatic session saving on logout qubes-desktop-linux-xfce4#33 (QubesOS/qubes-desktop-linux-xfce4@297aadd)
• Simplify systemd service qubes-dummy-psu#6 (QubesOS/qubes-dummy-psu@8528140)
• sys-gui: copy dpi from the host display qubes-gui-agent-linux#262 (QubesOS/qubes-gui-agent-linux@f795227)
• update 21.1.23+xephyr qubes-xorg-x11-server#1 (QubesOS/qubes-xorg-x11-server@4578e57)

Installing updates failed, skipping the report!

[marmarek]

I have some doubts about safety of this - if a qube leaves device in a weird state that would try to attack sys-usb. Here, the hope is device reset (like, re-plug) would restore it to a good state, but before that it would remain attached to usbip driver (that does nothing if device is not attached to any qube). But that's really a wishful thinking, no proof of that really helping. And device with persistent memory (like updateable firmware) could still perform an attack like this. And maybe even a compromised device could simulate re-plug event itself (to get attached to the default driver).
What do you think?
@HW42 maybe you have some opinion?

[piotrbartman]

I see a problem. Yes, it's some attack surface on sys-usb. In such a case, however, we need to specify what exactly the user should expect. Currently, we have:

USB stick plugged in -> partition exposed from sys-usb
USB stick attach to VM1 -> partition exposed from VM1
USB stick detach -> no partition exposed (confusion)
USB stick attach to VM2 -> partition exposed from VM2 (more confusion)
USB stick detach -> no partition exposed

VM2 is less protected than sys-usb.

I think we should choose one of the following:
(a) it should not be possible to connect the device to VM2 without hard reset, or
(b) it should be possible to expose the partition from sys-usb without a hard reset.

[marmarek]

I have two ideas of a middle ground solution:

• reset the device explicitly on detach (we have usb-reset script already)
• reattach only to popular drivers, like usb-storage, or uvcvideo

The second one is mostly heuristic, based on assumption that popular drivers are better reviewed/tested and more resilient against malicious hardware. But maybe first one is good enough already? (still depends on how much device cooperates, but all of this has this caveat...)

[HW42]

I have some doubts about safety of this

While this kind of was my first reaction too, I'm not sure there's really a realistic scenario where it helps.

if a qube leaves device in a weird state that would try to attack sys-usb. Here, the hope is device reset (like, re-plug) would restore it to a good state, but before that it would remain attached to usbip driver (that does nothing if device is not attached to any qube). But that's really a wishful thinking, no proof of that really helping. And device with persistent memory (like updateable firmware) could still perform an attack like this. And maybe even a compromised device could simulate re-plug event itself (to get attached to the default driver).

It depends on what you mean by weird state.

If this doesn't involve code execution on the USB device then it seems realistic that the attacker can not trigger a reconnect. But in this case I don't think it's that likely that they would be able to use that state to attack sys-usb, probably the device would just be in some semi-broken state.

If the attacker gets code execution (even without writable firmware), then most likely they can trigger a reconnect from the device (obviously depends on the specific hardware, but I think this is common). So here this doesn't help anyway.

Based on this I think the usability argument, seems reasonable.

In general for such usage having a minimal/locked-down sys-usb would be great, but that's another topic.

[HW42]

In case you want to play around with it here a little demo using a Raspbery Pi Pico: reset-test-v2.tar.gz