linux-kernel - Re: `quirk_usb_handoff_xhci` takes 60 ms with ASM1042

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 6 May 2021 10:23:00 -0500
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Paul Menzel <pmenzel@...gen.mpg.de>, linux-usb@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>,
        Mathias Nyman <mathias.nyman@...el.com>,
        linux-pci@...r.kernel.org
Subject: Re: `quirk_usb_handoff_xhci` takes 60 ms with ASM1042

On Wed, May 05, 2021 at 05:53:18PM +0200, Greg Kroah-Hartman wrote:
> On Wed, May 05, 2021 at 10:47:41AM -0500, Bjorn Helgaas wrote:
> > On Wed, May 05, 2021 at 02:31:56PM +0200, Greg Kroah-Hartman wrote:
> > > On Wed, May 05, 2021 at 02:15:26PM +0200, Paul Menzel wrote:
> > > > Am 05.05.21 um 10:33 schrieb Greg Kroah-Hartman:
> > > > > On Wed, May 05, 2021 at 10:27:52AM +0200, Paul Menzel wrote:
> > > > > > Am 05.05.21 um 10:11 schrieb Greg Kroah-Hartman:
> > 
> > > > > > > If the driver is built as a module, there should not be any "hot
> > > > > > > path" here as the module is loaded async when the device is
> > > > > > > discovered, right?
> > > > > >      obj-$(CONFIG_USB_PCI)   += pci-quirks.o
> > > > > > 
> > > > > > So all quirks are run independently of the USB “variant”
> > > > > > (UHCI, OHCI, EHCI, xHCI).
> > > > > > 
> > > > > > Indeed, this driver is built into the Linux kernel.
> > > > > > 
> > > > > >      $ grep USB_PCI .config
> > > > > >      CONFIG_USB_PCI=y
> > > > > > 
> > > > > > So, should `pci-quirks.c` be split up to have more fine
> > > > > > grained control?
> > > > > 
> > > > > What control do you need here?
> > > > 
> > > > Good question, as I do not know the USB spec. I’d say,
> > > > disabling certain quirks, or just run them, when the actual
> > > > driver is loaded.
> > > 
> > > This is not a "quirk", it is part of how USB works.
> > 
> > I agree, this doesn't look like a "quirk" in the sense of working
> > around a hardware defect; the handoff is just a normal part of
> > operating the device.  But can you elaborate on why it must be done
> > this way?
> > 
> > I'm looking at the xHCI r1.2 spec, sec 4.22.1.  It talks about the
> > handoff synchronization process and says the OS driver shall use the
> > defined protocol to request ownership before it uses the device.  But
> > AFAICT there's no specific "early-startup" requirement.
> > 
> > quirk_usb_handoff_xhci() is in drivers/usb/host/pci-quirks.c, which is
> > always built statically and the quirk runs during device enumeration,
> > even if the xhcd driver itself is a module.  It looks like we run the
> > quirk even if we never load the xhcd driver.
> > 
> > Why can't we just do the handoff in the xhcd driver probe?
> 
> I think, if we don't do the handoff, then the BIOS/firmware tries to
> send the OS fake keyboard/mouse commands, and Linux isn't ready for that
> as we didn't allow hotplug PS/2 stuff.  But I could be wrong, it's been
> a long time since we did that logic.

I have no idea what "BIOS/firmware sending OS fake keyboard/mouse
commands" means.  From the OS point of view, does that look like USB
events that cause PCI interrupts?  PS/2 interrupts?  Are these
commands caused by the user typing or moving the mouse?  Or does BIOS
fabricate commands for other reasons?

The way you describe it, this *sounds* like a race, where Linux
mishandles commands that happen before the handoff quirk.  Do you
remember what happens if BIOS sends a fake command before Linux is
ready for it?  Unexpected interrupt?

Bjorn