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] [day] [month] [year] [list]
Date:	Thu, 17 Dec 2015 11:24:15 -0800
From:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Daniel Vetter <daniel.vetter@...el.com>,
	Josh Boyer <jwboyer@...oraproject.org>
Cc:	Arend van Spriel <arend@...adcom.com>,
	Ming Lei <ming.lei@...onical.com>,
	Takashi Iwai <tiwai@...e.de>,
	Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
	"Jie, Yang" <yang.jie@...el.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	"joonas.lahtinen@...ux.intel.com" <joonas.lahtinen@...ux.intel.com>,
	Tom Gundersen <teg@...m.no>, Al Viro <viro@...iv.linux.org.uk>,
	Kay Sievers <kay@...y.org>,
	David Woodhouse <dwmw2@...radead.org>,
	lkml <linux-kernel@...r.kernel.org>,
	yalin wang <yalin.wang2010@...il.com>,
	Ming Lei <tom.leiming@...il.com>,
	linux-wireless <linux-wireless@...r.kernel.org>,
	linux-security-module <linux-security-module@...r.kernel.org>
Subject: Re: Problems loading firmware using built-in drivers with kernels
 that use initramfs.

On Sun, Aug 30, 2015 at 11:11 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Sun, Aug 30, 2015 at 1:25 AM, Arend van Spriel <arend@...adcom.com> wrote:
>> On 08/29/2015 12:38 PM, Ming Lei wrote:
>>
>> Does this mean a built-in driver can not get firmware from initramfs or
>> built in the kernel early. Seems a bit too aggressive.
>
> Yeah, that seems wrong. Loading firmware from initramfs is required
> for some things, like disk drivers. Of course, depending on how it's
> done, it's all after the SYSTEM_BOOTING phase, but ..
>
> What we *might* do is to not allow it for the user-mode helper
> fallback,

FWIW, that's what we did, request_firmware_direct() now skips the
silly usermode helper. I'll note that Greg pointed out to me that
Daniel (was this right?) might have some use cases for the usermode
helper in the future on graphics though. Daniel is that right? Can you
clarify the use case, I'd just like to document this and keep it in
mind for future design changes on firmware_class. Also, it occurs to
me that if you have a need for it, perhaps others might and if we can
avoid *others* from coming up with their own solution that'd be best,
specifically as this is related to file loading -- more on this later
generalized possible use cases in another thread I'll Cc you folks on.

> but I think it's more likely that we'll just deprecate the
> usermode helper fw loader entirely, so adding new error cases for it
> seems pointless.

I was shooting hard to deprecate the usermodehelper, Greg has noted
that we can only phase it out though, so that is what I will be
shooting for: a sysdata API, what will have firmware signing support
later will *not* make use of the usermode helper. The old APIs will
still use it.

[0] http://lkml.kernel.org/r/20151006090821.GB9030@kroah.com

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