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:	Sun, 01 Apr 2007 13:42:46 -0400
From:	David Zeuthen <davidz@...hat.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Maxim <maximlevitsky@...il.com>, Pete Zaitcev <zaitcev@...hat.com>,
	Alan Stern <stern@...land.harvard.edu>, gregkh@...e.de,
	Kernel development list <linux-kernel@...r.kernel.org>,
	USB development list <linux-usb-devel@...ts.sourceforge.net>
Subject: Re: USB: on suspend to ram/disk all usb devices are replugged

On Sun, 2007-04-01 at 15:29 +0000, Pavel Machek wrote:
> Hi!
> 
> > > > In that case the user would see data corruption - just as if he mounts a piece
> > > > of removable media in a USB card reader; yanks out the card and modifies it
> > > > elsewhere, and then puts it back in.
> > > 
> > > > I my opinion we can't really defend ourselves against such users... We can of
> > > > course add checks in the file system drivers in the resume hooks to validate the
> > > > super block and mount read-only if something change. 
> > > 
> > > The GNOME hath spoken?
> 
> > 	I also thought about that,
> > 	
> > 	I think that the best solution is still to hide connect/disconnect of usb devices from userspace (now it also causes corruption)
> > 	But to refuse suspend with any usb mass storage device connected with mounted systems (and add a module param override
> > 	 for users who know what they are doing)
> > 
> > 	What do you think ?
> 
> Agreed... and notice how easy is to do that in userspace :-))).
> 

The problem with refusing to suspend with usb mass storage devices
mounted is just not going to work; the way we want desktop power
management to work is that the system automatically does s2ram or s2disk
when

 - the system is idle
 - the user closes the laptop lid
   (all this is of course configurable but these are the defaults
    in many distributions of Linux.)

and the kernel refusing to suspend in these cases may result in e.g. the
laptop melting because the lid is closed. For example, in
gnome-power-manager we play a loud "boohoo" sound if suspend fails when
closing the lid. It's all we can do really, the user have closed the lid
and if we didn't alert her _in some way_ the result would be a melted
laptop. You have to realize that people use their system in such a way.

Suspending when idle is really important too, since at some point there
will be legislation (akin to accessibility, e.g. the US's section 508)
that mandates that e.g. the US government will not buy systems that
don't conserve power by going to sleep when idle. That's an incentive at
least for "enterprise distributions" to fix this; more importantly, I
personally think that we have a moral obligation to do all that we can
to conserve power. Refusing to suspend means that many systems with USB
mass storage devices attached will consume e.g. 300W instead of 8W. I
don't know about you, but that sounds awfully wasteful to me.

And there's this: suggesting to just provide an option for people to
override this is not useful; any sane desktop distro will use that
override because users _expect_ that their laptop suspends when they
close the lid and they don't really or know care whether some drive is
connected via USB.

I hate to play this card, but you may want to look at other desktop
operating systems like Mac OS X and Windows - they don't give you USB
disconnects/reconnects on suspend and apps runs fine and can continue
accessing files on mounted USB devices upon resume.

I hope this clarifies the request. Thanks for considering.

      David


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ