q-dev: avoid zombie USB device#55
Conversation
After detaching from the frontend vm, the 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).
OpenQA test summaryComplete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2026053102-devel&flavor=pull-requests Test run included the following:
New failures, excluding unstableCompared to: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2026050504-devel&flavor=update
Failed tests56 failures
Fixed failuresCompared to: https://openqa.qubes-os.org/tests/176874#dependencies 21 fixed
Unstable testsDetails
Performance TestsPerformance degradation:26 performance degradations
Remaining performance tests:85 tests
|
|
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). |
|
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: VM2 is less protected than sys-usb. I think we should choose one of the following: |
|
I have two ideas of a middle ground solution:
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...) |
minimize chance of device persistent state attack
While this kind of was my first reaction too, I'm not sure there's really a realistic scenario where it helps.
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. |
|
In case you want to play around with it here a little demo using a Raspbery Pi Pico: reset-test-v2.tar.gz |
4 participants
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).