Limit USB 1.0 (UHCI/OCHI) and 2.0 (EHCI) to non-virt use cases

Limit USB 1.0 (UHCI/OCHI) and 2.0 (EHCI) to non-virt use cases

[Daniel P. Berrangé]

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-case


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-case


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 :|

Re: Limit USB 1.0 (UHCI/OCHI) and 2.0 (EHCI) to non-virt use cases

[Helge Deller]

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-case
> 
> 
> 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-case
> 
> 
> 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