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] [day] [month] [year] [list]

Message-ID: <20210506155939.GA738638@rowland.harvard.edu>
Date:   Thu, 6 May 2021 11:59:39 -0400
From:   Alan Stern <stern@...land.harvard.edu>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        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 Thu, May 06, 2021 at 10:23:00AM -0500, Bjorn Helgaas wrote:
> On Wed, May 05, 2021 at 05:53:18PM +0200, Greg Kroah-Hartman wrote:
> > 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?

Think of an old MSDOS operating system without USB support.  The BIOS 
tries to be helpful by translating mouse and keyboard input it receives 
over USB into PS/2 events that the operating system can handle.  
Originally this was done using SMI; now it presumably is still a legacy 
part of UEFI.

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

I would be surprised if anybody still knows.  :-)

Perhaps a reasonable experiment would be to boot a kernel with PS/2 
support but not USB support (or at least, without CONFIG_USB_PCI) and 
see what happens when you type on the USB keyboard or move the USB 
mouse.

It might very well turn out that the handoff operation can safely be 
delayed until driver probe time.

Alan Stern