linux-kernel - Re: loading firmware while usermodehelper disabled.

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: <20120103005839.618af359@pyramind.ukuu.org.uk>
Date:	Tue, 3 Jan 2012 00:58:39 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Jack Stone <jwjstone@...tmail.fm>
Cc:	Marek Vasut <marek.vasut@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Oliver Neukum <oliver@...kum.org>,
	Matthew Garrett <mjg@...hat.com>,
	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>,
	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.

> >Hm ... and we can't have memory type that "can be swapped-out, but must
> >be 
> >loaded back before suspend" in kernel, right?
> 
> Nope. Kernel swapping is a big headache and Linux doesn't do it. The only thing we can do is drop any clean cache pages, but that has performance implications.

You could however have an arrangement where the firmware refmanager does
a list of request_firmware()s at the very start of the suspend process. It
cannot be done during suspend for obvious reasons (sorry I already
suspended the hard disk) but it can be done just before.

In that case with get/put_firmware you'd just need to extend the API to

	get_firmware()
	put_firmware()
	get_for_suspend_firmware()

and a driver might do something like

module_init

	fw = get_for_suspend_firmware("wombatdepolariser.fw");

open:  /* just optimising */
	kref_get(&fw->kref);

close:
	put_firmware(fw);

module_unload:
	put_firmware(fw);

Now the uglier side of that is how you make sure that if
get_for_suspend_firmware() works that when we suspend the firmware is
present. We could keep the file handle open but that might block unmounts
or we could assume that as its superuser stuff that the distro authors
don't screw up - in which case we'd refuse to suspend with a nasty
complaint if the firmware turned out to have been deleted behind our back.

You'd also have to be in situation where new device probes were not
processed but userspace (eg the fw loader helper) were still running.

That seems to me to be a useful optimisation project for bigger firmwares
but not something to implement on day 1 ?

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