linux-kernel - Re: [RFC] firmware load: defer request_firmware during early boot and resume

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, 22 Jul 2012 12:46:13 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Borislav Petkov <borislav.petkov@....com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ming Lei <tom.leiming@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-usb <linux-usb@...r.kernel.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Oliver Neukum <oneukum@...e.de>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [RFC] firmware load: defer request_firmware during early boot and resume

On Sun, Jul 22, 2012 at 5:58 AM, Borislav Petkov <bp@...en8.de> wrote:
>
> Question: is there any other reason
>
>   [besides maybe embedded people who care about each single Kb of memory
>    on the system]
>
> why we don't make this cache/uncache firmware thing *implicit*? That is,
> load it once at driver open time and keep it in memory during the whole
> driver's lifetime. And this all taken care of by the driver core, btw.

So some firmware is a *lot* more than "a few kB". We're talking
hundreds of kB, sometimes more. And to make matters worse, we keep it
in memory with vmalloc(), which is a limited resource on 32-bit
systems. So it can actually be worse than just the memory use itself.

Also, as you already mentioned, there's the "cache coherency" issue.
There are real advantages to reloading the firmware occasionally,
because it might have changed on disk. So..

I do think we might want to consider it, although I do suspect that we
do want to throw it out because of the problems with infinite caches.

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