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