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

["Daniel P. Berrangé" <berrange@redhat.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:
> >
> > 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 :|