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, 1 Jan 2012 10:54:47 +0100
From:	Marek Vasut <marek.vasut@...il.com>
To:	Oliver Neukum <oliver@...kum.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Larry Finger <Larry.Finger@...inger.net>,
	Chaoming Li <chaoming_li@...lsil.com.cn>,
	"John W. Linville" <linville@...driver.com>,
	Matthew Garrett <mjg@...hat.com>,
	"Greg Kroah-Hartman" <gregkh@...e.de>,
	USB list <linux-usb@...r.kernel.org>,
	Linux Wireless List <linux-wireless@...r.kernel.org>
Subject: Re: loading firmware while usermodehelper disabled.

> Am Samstag, 31. Dezember 2011, 19:39:18 schrieb Marek Vasut:
> > maybe we should implement such thing into the firmware loader itself?
> > Allow it -- for example via some node in /dev -- to force loading
> > firmware into some buffer in kernel just before suspend so it'll
> > certainly be readily available at resume time?
> 
> This is difficult. We don't know at suspend time which firmware we will
> need at resume time.

That's not actually true ... you can ask the drivers if they need to load 
firmware after resume ... that can be implemented and udev can handle it. The 
driver should know if the hardware it's controlling is stupid or not.

> We could keep a record of firmware we needed
> to get to the state we are, but this is a very complex scheme.

Not really. You might have a device where you load firmware, issue suspend 
command and then issue resume command, while the device will still retain 
firmware in it, it'll be only in low power mode throughout the sleep cycle.

Then you can have a device that will just power down completely, wiping the 
firmware from it's memory. And that's what should be taken care of by injecting 
the firmware before suspend. The driver should be able to tell you if the device 
is broken and needs this special treatment.

This will though delay the time to suspect slightly, but that can be considered 
a price you have to pay if your hardware is stupid.

M
> 
> 	Regards
> 		Oliver
--
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