Limit USB 1.0 (UHCI/OCHI) and 2.0 (EHCI) to non-virt use cases
QEMU has implemented four generic USB controllers * UHCI - USB 1.0 only * OHCI - USB 1.0 only * EHCI - USB 2.0 only (must have UHCI companions for 1.0 compat) * XHCI - All of USB 3.0, 2.0, 1.0 in one controller We have two variants of XHCI, the generic one (hcd-xhci.c) and the NEC one (hcd-xhci-nec.c) Historically for security reports we have considered all of them in scope of virtualization, since initially with KVM the XHCI impl was not present in QEMU & thus KVM guests used UHCI/EHCI with USB tablet for a period of time All of the USB subsystem is currently orphaned, so we have no dedicated maintainer available to deal with bug reports (volunteers welcome to step up here...) While the need for USB is reduced given the availability of virtio-input, not all guests have drivers out of the box, so at least USB tablet is still interesting for KVM use cases with some modern OS. It is also not that unusual for people to need USB host device assignment with KVM virt to make various pieces of specialized hardware (security tokens, smart cards, custom dongles, etc) available directly to guests. IOW, we can't entirely exclude USB from virtualization use cases IMHO. In terms of virtualization, XHCI is the only impl that is sensible to use. UHCI/OHCI/EHCI all impose an unreasonable CPU load on any guest usage of USB. XHCI should be supported by any guest OS approx the last 15 years, which should be sufficient for virtualization use cases with OS that are not EOL by their vendor. Thus to reduce our maint burden around security bug handling, it is proposed henceforth to classify UHCI, OHCI and EHCI under the non- virtualization use case and thus be excluded from security bug triage processes. No CVEs would be assigned, bugs would be reported publically in gitlab: https://www.qemu.org/docs/master/system/security.html#non-virtualization-use... The XHCI controller (specifically the hcd-xhci.c variant) would remain as our only option for the virtualization use case, with security process applied to bugs & eligible for CVE assignment: https://www.qemu.org/docs/master/system/security.html#virtualization-use-cas... The other NEC XHCI variant (hcd-xhci-nec.c) would also be treated as non-virtualization use case, since it needlessly duplicates hcd-xhci.c impl and thus is only interesting for emulation of this specific HW variant. NB, there are no functional limitations / restrictions from this policy, it is largely just a semantic exercise. From a management application POV, however, it would strongly suggest that guests be configured with XHCI as the default choice if the user asks for USB, and in turn also imply that '-usb' not be used since that is UHCI/OHCI typically. CC'ing libvirt, though it is really a matter for virt-install/virt-manager/ openstack/kubevirt etc above libvirt to pick their defaults for USB controllers. None the less XHCI would still be in search of a maintainer to step forward and handle ongoing development and maint work. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
On 5/13/26 11:22, Daniel P. Berrangé wrote:
QEMU has implemented four generic USB controllers
* UHCI - USB 1.0 only * OHCI - USB 1.0 only * EHCI - USB 2.0 only (must have UHCI companions for 1.0 compat) * XHCI - All of USB 3.0, 2.0, 1.0 in one controller
We have two variants of XHCI, the generic one (hcd-xhci.c) and the NEC one (hcd-xhci-nec.c)
Historically for security reports we have considered all of them in scope of virtualization, since initially with KVM the XHCI impl was not present in QEMU & thus KVM guests used UHCI/EHCI with USB tablet for a period of time
All of the USB subsystem is currently orphaned, so we have no dedicated maintainer available to deal with bug reports (volunteers welcome to step up here...)
While the need for USB is reduced given the availability of virtio-input, not all guests have drivers out of the box, so at least USB tablet is still interesting for KVM use cases with some modern OS.
It is also not that unusual for people to need USB host device assignment with KVM virt to make various pieces of specialized hardware (security tokens, smart cards, custom dongles, etc) available directly to guests.
IOW, we can't entirely exclude USB from virtualization use cases IMHO.
In terms of virtualization, XHCI is the only impl that is sensible to use. UHCI/OHCI/EHCI all impose an unreasonable CPU load on any guest usage of USB. XHCI should be supported by any guest OS approx the last 15 years, which should be sufficient for virtualization use cases with OS that are not EOL by their vendor.
Thus to reduce our maint burden around security bug handling, it is proposed henceforth to classify UHCI, OHCI and EHCI under the non- virtualization use case and thus be excluded from security bug triage processes. No CVEs would be assigned, bugs would be reported publically in gitlab:
https://www.qemu.org/docs/master/system/security.html#non-virtualization-use...
The XHCI controller (specifically the hcd-xhci.c variant) would remain as our only option for the virtualization use case, with security process applied to bugs & eligible for CVE assignment:
https://www.qemu.org/docs/master/system/security.html#virtualization-use-cas...
The other NEC XHCI variant (hcd-xhci-nec.c) would also be treated as non-virtualization use case, since it needlessly duplicates hcd-xhci.c impl and thus is only interesting for emulation of this specific HW variant.
NB, there are no functional limitations / restrictions from this policy, it is largely just a semantic exercise. From a management application POV, however, it would strongly suggest that guests be configured with XHCI as the default choice if the user asks for USB, and in turn also imply that '-usb' not be used since that is UHCI/OHCI typically. CC'ing libvirt, though it is really a matter for virt-install/virt-manager/ openstack/kubevirt etc above libvirt to pick their defaults for USB controllers.
I support this proposal. It keeps the "commercial side" of qemu ("KVM") more secure by defining which drivers (XHCI) are fully supported and should ideally be used, while still allowing to use the other USB drivers for the IMHO less-used and less-critical use cases (e.g. foreign hardware emulation). Helge
On Wed, 13 May 2026 at 10:23, Daniel P. Berrangé <berrange@redhat.com> wrote:
QEMU has implemented four generic USB controllers
* UHCI - USB 1.0 only * OHCI - USB 1.0 only * EHCI - USB 2.0 only (must have UHCI companions for 1.0 compat) * XHCI - All of USB 3.0, 2.0, 1.0 in one controller
Thus to reduce our maint burden around security bug handling, it is proposed henceforth to classify UHCI, OHCI and EHCI under the non- virtualization use case and thus be excluded from security bug triage processes. No CVEs would be assigned, bugs would be reported publically in gitlab:
The XHCI controller (specifically the hcd-xhci.c variant) would remain as our only option for the virtualization use case, with security process applied to bugs & eligible for CVE assignment:
I support this; I don't think there's any reason to use anything except XHCI in a modern VM, and the others are useful now largely in the emulation and retrocomputing areas. I guess my question is how we communicate this to users, and whether there's some sort of timescale or if it's just "effective immediately". If we're fairly confident nobody's really using the old controllers in production then I guess we can just commit the policy update to security.rst and that then appears on the website ? -- PMM
On Fri, May 15, 2026 at 08:49:24AM +0100, Peter Maydell wrote:
On Wed, 13 May 2026 at 10:23, Daniel P. Berrangé <berrange@redhat.com> wrote:
QEMU has implemented four generic USB controllers
* UHCI - USB 1.0 only * OHCI - USB 1.0 only * EHCI - USB 2.0 only (must have UHCI companions for 1.0 compat) * XHCI - All of USB 3.0, 2.0, 1.0 in one controller
Thus to reduce our maint burden around security bug handling, it is proposed henceforth to classify UHCI, OHCI and EHCI under the non- virtualization use case and thus be excluded from security bug triage processes. No CVEs would be assigned, bugs would be reported publically in gitlab:
The XHCI controller (specifically the hcd-xhci.c variant) would remain as our only option for the virtualization use case, with security process applied to bugs & eligible for CVE assignment:
I support this; I don't think there's any reason to use anything except XHCI in a modern VM, and the others are useful now largely in the emulation and retrocomputing areas.
I guess my question is how we communicate this to users, and whether there's some sort of timescale or if it's just "effective immediately". If we're fairly confident nobody's really using the old controllers in production then I guess we can just commit the policy update to security.rst and that then appears on the website ?
I'm intending to update this series real soon: https://lists.gnu.org/archive/html/qemu-devel/2025-09/msg05781.html We could also make this more explicit in the USB docs https://www.qemu.org/docs/master/system/devices/usb.html Since sending this mail, I realized that while (AFAIK) all apps are using XHCI for provisioning new guests, RHEL still ships UCHI/EHCI drivers. IOW from Red Hat's POV, we still need security bug coverage for these devices, even if they're discouraged upstream. I'm trying to see if we can get someone to take up maintainership, even if just on an odd fixes basis, as without a maintainer I don't think it is reasonable to expect upstream to promise any kind of security bug support. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
On Fri, May 15, 2026 at 08:49:24AM +0100, Peter Maydell wrote:
On Wed, 13 May 2026 at 10:23, Daniel P. Berrangé <berrange@redhat.com> wrote:
The XHCI controller (specifically the hcd-xhci.c variant) would remain as our only option for the virtualization use case, with security process applied to bugs & eligible for CVE assignment:
I support this; I don't think there's any reason to use anything except XHCI in a modern VM, and the others are useful now largely in the emulation and retrocomputing areas.
I fully support that too, recommending xhci since 2018 ;) https://www.kraxel.org/blog/2018/08/qemu-usb-tips/ Except for the claim that windows 7 is in widespread use this still applies today. take care, Gerd
On Mon, 18 May 2026 at 11:53, Gerd Hoffmann <kraxel@redhat.com> wrote:
On Fri, May 15, 2026 at 08:49:24AM +0100, Peter Maydell wrote:
On Wed, 13 May 2026 at 10:23, Daniel P. Berrangé <berrange@redhat.com> wrote:
The XHCI controller (specifically the hcd-xhci.c variant) would remain as our only option for the virtualization use case, with security process applied to bugs & eligible for CVE assignment:
I support this; I don't think there's any reason to use anything except XHCI in a modern VM, and the others are useful now largely in the emulation and retrocomputing areas.
I fully support that too, recommending xhci since 2018 ;)
https://www.kraxel.org/blog/2018/08/qemu-usb-tips/
Except for the claim that windows 7 is in widespread use this still applies today.
Is it still the case that the "-usb" QEMU option gives you the old OHCI/UHCI controller? (My quick look at the source code suggests it is.) If so, that's an unfortunate default, since it makes it very easy to pick the non-security-supported bad config by accident. Could we make "-usb" give the PC machines an XHCI controller for new machine version types ? thanks -- PMM
On Mon, May 18, 2026 at 12:00:02PM +0100, Peter Maydell wrote:
On Mon, 18 May 2026 at 11:53, Gerd Hoffmann <kraxel@redhat.com> wrote:
I fully support that too, recommending xhci since 2018 ;)
https://www.kraxel.org/blog/2018/08/qemu-usb-tips/
Except for the claim that windows 7 is in widespread use this still applies today.
Is it still the case that the "-usb" QEMU option gives you the old OHCI/UHCI controller? (My quick look at the source code suggests it is.) If so, that's an unfortunate default, since it makes it very easy to pick the non-security-supported bad config by accident.
It was still the case when I stopped maintaining usb and it is unlikely it has changed since.
Could we make "-usb" give the PC machines an XHCI controller for new machine version types ?
Sounds reasonable to me. libvirt has changed defaults years ago. take care, Gerd
participants (4)
-
Daniel P. Berrangé -
Gerd Hoffmann -
Helge Deller -
Peter Maydell