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=2026071723-devel&flavor=pull-requests Test run included the following:
Upload failures
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 25 fixed
Unstable testsDetails
Performance TestsPerformance degradation:19 performance degradations
Remaining performance tests:91 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 Jun 6, 2026
This was referenced Jun 15, 2026
This was referenced Jul 10, 2026
This was referenced Jul 18, 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).