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

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

[Peter Maydell]

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

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

[Daniel P. Berrangé]

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

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

[Gerd Hoffmann]

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

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

[Peter Maydell]

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

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

[Gerd Hoffmann]

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