linux-kernel - Re: [GIT PATCH] USB autosuspend fixes for 2.6.23-rc6

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.0709131111460.3619-100000@iolanthe.rowland.org>
Date:	Thu, 13 Sep 2007 11:20:42 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Adrian Bunk <bunk@...nel.org>
cc:	Greg KH <gregkh@...e.de>, Linus Torvalds <torvalds@...l.org>,
	Andrew Morton <akpm@...l.org>, <linux-kernel@...r.kernel.org>,
	<linux-usb-devel@...ts.sourceforge.net>,
	Oliver Neukum <oneukum@...e.de>
Subject: Re: [GIT PATCH] USB autosuspend fixes for 2.6.23-rc6

On Thu, 13 Sep 2007, Adrian Bunk wrote:

> > These two patches address the need today to have users machines still
> > work, even if they might draw more power than they possibly could (which
> > is not any more than they did in 2.6.22.)
> > 
> > These patches do two things:
> >   - disable USB autosuspend on all devices except for USB hubs.  This
> >     can be easily overridden by userspace to turn on autosuspend for
> >     devices that a user wants to.  HAL will use a whitelist in the
> >     future for these types of devices.
> >...
> 
> Not related to the patch for 2.6.23, but I have a gut feeling that 
> something might be done the wrong way later:
> 
> If I understand you correctly, you are saying that I will have to 
> install HAL for getting a whitelist for in-kernel functionality?

Your meaning isn't entirely clear.  Presumably HAL will contain such a 
whitelist.  But there's nothing to stop you from setting up your own 
whitelist via udev scripts, or even turning autosuspend on or off by 
hand.

> It is a good thing if userspace can add currently missing devices to
> whitelists, but the whitelist itself should be in the kernel.

It's not clear that this sort of approach will turn out to be workable.  
Whitelists/blacklists do okay in the kernel when they refer to a 
relatively small subset of devices.  However in this case I have the 
impression that we're talking about roughly a 50/50 split.  Keeping an 
in-kernel list with even 10% of all existing USB devices simply isn't 
feasible.

Besides, is it really that much harder for userspace to modify device
settings as the devices are detected than for it to modify an in-kernel
whitelist just once?  Don't forget about possible races: Devices may
already have been detected and configured before userspace was able to
modify the whitelist.

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/