linux-kernel - Re: [Linux-usb-users] OHCI root_port

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]

Message-ID: <Pine.LNX.4.44L0.0710091156100.4783-100000@iolanthe.rowland.org>
Date:	Tue, 9 Oct 2007 12:01:54 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	David Miller <davem@...emloft.net>
cc:	Greg KH <greg@...ah.com>, David Brownell <david-b@...bell.net>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	USB users list <linux-usb-users@...ts.sourceforge.net>
Subject: Re: [Linux-usb-users] OHCI root_port_reset() deadly loop...

On Mon, 8 Oct 2007, David Miller wrote:

> As coicidence would have it I finally found a recipe for triggering
> the issue, and it ties into what you're talking about here.
> 
> It happens only if I make sure OHCI gets loaded first and then EHCI
> right afterwards.
> 
> It seems that indeed it is important for EHCI to get loaded first,
> and in-kernel this is ensured by the link ordering.
> 
> However, when both OHCI and EHCI are built as modules (or, similarly
> I guess, OHCI is built-in and EHCI is modular) there appears to be
> nothing in userspace which makes sure EHCI gets loaded first.
> 
> When this triggers, in OHCI's root_port_reset(), the port status
> register reads 0x111 in that inner-loop and the value never changes.
> It stays like this forever.

I agree with Ben; the best way to solve this is in the kernel.  Even if 
you did manage to make sure that modules were loaded in the right order 
initially, that wouldn't help if somebody starts unloading and loading 
modules by hand.

The underlying cause of the problem appears to be related to the fact
that it is impossible in principle to detect a disconnect while a
full/low-speed reset is in progress.  However the hardware shouldn't
rely on this, and it should fail gracefully when an unexpected
disconnect does occur.

For example, what would the controller do if the user unplugged the USB 
cable right in the middle of a reset?

Anyway, it certainly would be easy enough to make port resets mutually
exclusive with EHCI initialization.  That would work on any platform,
PCI or not.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/