You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A feature request was opened in fwupd for handling systems with usbguard. The crux of the issue is that some USB devices while they go through a firmware update sequence would be disconnected and put into a special flashing mode and reconnected. While in that mode, the USB VID/PID will likely have changed to a "bootloader" VID/PID.
If a user has enabled usbguard on their machine the policy is very unlikely to have already covered the bootloader VID/PID. Because of this the firmware update will fail, and worse the device might be "stuck" in bootloader mode. Most devices can recover with a power cycle, but this is of course not an expected behavior.
So because of all of this, I wanted ask from a usbguard perspective how should we handle this situation? Is it better to have a dbus call to inhibit usbguard momentarily while running an update? Or for fwupd to temporarily register a policy for the expected bootloader VID/PID? We often do know what the VID/PID will be as we need to look for it after the update.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
A feature request was opened in fwupd for handling systems with usbguard. The crux of the issue is that some USB devices while they go through a firmware update sequence would be disconnected and put into a special flashing mode and reconnected. While in that mode, the USB VID/PID will likely have changed to a "bootloader" VID/PID.
If a user has enabled usbguard on their machine the policy is very unlikely to have already covered the bootloader VID/PID. Because of this the firmware update will fail, and worse the device might be "stuck" in bootloader mode. Most devices can recover with a power cycle, but this is of course not an expected behavior.
So because of all of this, I wanted ask from a usbguard perspective how should we handle this situation? Is it better to have a dbus call to inhibit usbguard momentarily while running an update? Or for fwupd to temporarily register a policy for the expected bootloader VID/PID? We often do know what the VID/PID will be as we need to look for it after the update.
Appreciate your thoughts!
Beta Was this translation helpful? Give feedback.
All reactions