Unable to update Nitrokey 3 within an app qube #8953
Labels
affects-4.2
This issue affects Qubes OS 4.2.
C: usb proxy
diagnosed
Technical diagnosis has been performed (see issue comments).
hardware support
P: default
Priority: default. Default priority for new issues, to be replaced given sufficient information.
pr submitted
A pull request has been submitted for this issue.
r4.1-bookworm-stable
r4.1-bullseye-stable
r4.1-buster-stable
r4.1-dom0-stable
r4.1-fc37-stable
r4.1-fc38-stable
r4.1-fc39-stable
r4.2-host-stable
r4.2-vm-bookworm-stable
r4.2-vm-fc37-stable
r4.2-vm-fc38-stable
r4.2-vm-fc39-stable
r4.2-vm-fc40-stable
r4.2-vm-trixie-stable
r4.3-host-cur-test
r4.3-vm-bookworm-cur-test
r4.3-vm-fc39-cur-test
r4.3-vm-fc40-cur-test
r4.3-vm-trixie-cur-test
T: bug
Type: bug report. A problem or defect resulting in unintended behavior in something that exists.
Comments
nestire
added
P: default
|
Any kernel errors on either side of the connection? |
|
dmesg looks normal in sys-usb and the app-vm in all cases |
|
here is the dmesg of sys-usb and personal. I did the process 2. times firstime Qubes did not recognize the new device in sys-usb |
|
ok after looking at it again and in sys-usb: does actually not look normal but they also appear if I attach just the nitrokey3 and don't reboot into the boot loader and seem not to affect the connection (can do nitropy nk3 list and other commands without a problem) |
|
I tried to reproduce the problem with usbip over the network with a non-Qubes OS but everything worked fine in this setup (both machines using Linux 6.1.76). |
|
ok did some more testing and some "workarounds": A:
if you skip step 3 it does not work
|
|
interesting... maybe it's something about a driver in sys-usb automatically attaching to the device and messing with the process? |
|
That might well be the case! Could a userspace daemon (patched usbguard?), together with |
andrewdavidwong
changed the title
andrewdavidwong
added
hardware support
needs diagnosis
|
Have the same behavior all the time when attaching usb security dongles to qemu in a vm. No fun. Updates? |
This was referenced May 24, 2024
|
@marmarek @DemiMarie this a big blocker for all USB devices changing roles, inlcluding android phones for usb tethering, debugging etc which are long lasting issues where people are doing more and more crazy stuff inside of sys-usb as a mitigation from this unfixed bug under QubesOS. (On my side ddging testing of USB passthrough physical dongles altogether in my dev cycles and now relying on qemu-canokey and cakokey-qemu library as now used under Heads since linuxboot/heads#1671 and qemu-canokey now being merged and going to land under nixos-unstable soon NixOS/nixpkgs#194254) For what interests us here needing upstream (qubesos prioritized fix): |
TracesMeanwhileqube side: dmesg on qube side: sys-usb side: dmesg on sys-usb: |
|
FWIW the Android issue was identified as something else already, and not even specific to qubes: #6330 (comment). So, this issue is really only about Nitrokey. |
|
@marmarek @DemiMarie qvm-usb should permit interfacing in terms of "pid:vid", just like qemu, usbreset and all other usb tooling permits to interact with detected usb devices. Otherwise, usb port doesn't change, but pid:vid does and consumers (destination qube) get confused, with reason. the destination qube "thinks" the device (pid:vid) is still connected but it isn't, resulting in timeouts. This is a bug/feature of qvm-usb device assignation which shouldn't be usb port but pid:vid. Maybe the interface itself should not change, but the permanence option should bind to pid:vid so that it's not the usb port that is binding, but the subjescent pid:vid? The issue at play here is that qvm-usb thinking the usb port has not been disconnected, even if the description of the device has changed, it is already assigned with the destination qube, even if the "pid:vid" changed. If qvm-usb could permit to assign permanently pid:vid instead of usb port, or in combination of a usb port for identity change management, this and other collateral issues might as well vanish altogether. Details under Nitrokey/nitrokey-documentation#248 (comment) |
|
I tried to reproduce it, but it works for me. I have Nitrokey 3A Mini, here is what I did:
At this point I unplugged it and plugged again, basically repeating steps until
Here As for the logs, I do see in sys-usb entries like |
|
On my side I have nk3 3a nfc, on 1.5.0 and cannot replicate success Note that to me, this is Traces |
Mine in bootloader mode is 20a0:42e8, so maybe I have a different hardware that is not affected by this issue? |
@daringer not sure but as long as users will not be able to all upgrade, more investigation is needed |
This would be a security vulnerability, as it would allow spoofing attacks.
The port number is the only information that is not under the control of a device. Therefore, including it in the information used to identify a device is a security requirement. Not using it would allow spoofing attacks. Would it be sufficient to emulate unplugging and replugging the device? |
|
@DemiMarie I just spent some time debugging it with @tlaurion and the vid:pid hypothesis looks to be dead end, so lets cut this topic in here. The actual issue seems to be hardware related (or more likely - related to chip bootloader), and maybe also related to specific hardware revision, not necessarily all devices. |
Thank you @DemiMarie @marmarek :) |
|
Automated announcement from builder-github The package |
|
Automated announcement from builder-github The component |
|
Automated announcement from builder-github The component |
|
Automated announcement from builder-github The component |
|
Automated announcement from builder-github The component |
|
Automated announcement from builder-github The component Or update dom0 via Qubes Manager. |
marmarek
added a commit
to QubesOS/qubes-core-admin-client
that referenced
this issue
Nov 5, 2024
QubesOS/qubes-issues#8953 (cherry picked from commit 621539e)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Qubes OS release
4.2.1 Fedora Templates
Brief summary
We try to integrate the Nitrokey3 Firmware updates in Qubes. In this process the Nitrokey3 is rebooted into a Bootloader which then handles the update. This disconnects the Niktrokey3 from the app-vm and a new device appears. When we attach this device manual from sys-usb to the app-vm, it appears but the connection then fails. This is specific for LPC 55 variant of the Nitrokey3.
Steps to reproduce
nitropy nk3 listin the app-vm to check if it is connectednitropy nk3 reboot --bootloaderto reboot the nitrokey3 into the bootloadernitropy nk3 listCritical error:
An unhandled exception occurred
Exception encountered: McuBootConnectionError()
Expected behavior
basically the same behavior when you run nitropy directly in sys-usb
Actual behavior
see above
usb_traffic_dump_wireshark.zip
2 wiresharke dump of the traffic on the usb interface in the app-vm of this process and in sys-usb (which works)
The text was updated successfully, but these errors were encountered: