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]

Date:	Sun, 01 Jan 2012 22:45:15 +0000
From:	Jack Stone <jwjstone@...tmail.fm>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	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.

On 31/12/11 00:22, Linus Torvalds wrote:
> It's also possible that we should blame the firmware code, which is
> expressly written to encourage these kinds of bugs. It may be that i
> tshould be the firmware code that has a "get_firmware()" +
> "put_firmware()" model, and it should cache the firmware explicitly if
> the config supports suspend, so that a firmware read at resume time
> would actually work. The whole "request_firmware()" interface really
> is very prone to these kinds of bugs.

How about these semantics for get_firmware / put_firmware:

get_firmware -> checks for a cached copy of the firmware and returns
that if it exists otherwise calls _get_firmware (i.e.
_request_firmware). Either way we get a refcount to the firmware blob.
This requires adding 3 members to struct firmware: the refcount, the
name of the firmware (see @name in request_firmware) and a list head to
cache with. We could also add and async version of this to match
request_firmware_nowait.

put_firmware -> Removes a refcount from the firmware and frees if there
are no more users.

put_firmware is called when we are sure that we no longer need to reload
the firmware for that device - device close time for most drivers.

USB is a more difficult case as devices can change ID but the firmware
blob still needs to be associated with them. I don't know USB at all so
I have no idea if we can track this. Some PCI devices may also suffer
the same problem.

Hope this is useful,

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