q-dev: avoid zombie USB device#55
Open
piotrbartman wants to merge 2 commits into
Open
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=2026062113-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 tests22 failures
Fixed failuresCompared to: https://openqa.qubes-os.org/tests/176874#dependencies 20 fixed
Unstable testsDetails
Performance TestsPerformance degradation:32 performance degradations
Remaining performance tests:78 tests
|
This was referenced May 5, 2026
Merged
This was referenced May 6, 2026
Merged
Member
|
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). |
Member
Author
|
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: |
Member
|
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...) |
This was referenced May 15, 2026
This was referenced May 25, 2026
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 |
This was referenced May 30, 2026
tests: do not fail dispvm+thunderbird test early if TB is not installed
QubesOS/qubes-core-admin#817
Merged
This was referenced Jun 6, 2026
This was referenced Jun 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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).