linux-kernel - Re: Problems loading firmware using built-in drivers with kernels that use initramfs.

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: <55E6E7FD.8030401@broadcom.com>
Date:	Wed, 2 Sep 2015 14:13:49 +0200
From:	Arend van Spriel <arend@...adcom.com>
To:	"Luis R. Rodriguez" <mcgrof@...e.com>,
	Ming Lei <ming.lei@...onical.com>
CC:	Takashi Iwai <tiwai@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	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>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Kay Sievers <kay@...y.org>,
	David Woodhouse <dwmw2@...radead.org>,
	"Luis Rodriguez" <mcgrof@...not-panic.com>,
	lkml <linux-kernel@...r.kernel.org>,
	yalin wang <yalin.wang2010@...il.com>
Subject: Re: Problems loading firmware using built-in drivers with kernels
 that use initramfs.

On 09/02/2015 02:09 PM, Arend van Spriel wrote:
> On 09/02/2015 03:19 AM, Luis R. Rodriguez wrote:
>> On Mon, Aug 31, 2015 at 10:21:34PM +0800, Ming Lei wrote:
>>> On Sun, Aug 30, 2015 at 4:25 PM, Arend van Spriel
>>> <arend@...adcom.com> 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. The problem
>>>> stated in
>>>> this thread is when the firmware is not on initramfs but only on the
>>>> rootfs.
>>>
>>> Yes, strictly speaking, user mode request can't be handled with defer
>>> probe
>>> during booting because we don't know how the user helper handles the
>>> request,
>>
>> FWIW I have a strategy in mind to help us compartamentalize the user mode
>> helper only to the dell-rbu driver, and as such phase out that code
>> eventually
>> completely. Its part of the goals I have with the extensible firmware
>> API I've
>> been proposing.
>>
>>> that said even checking if the firmware exists in current path doesn't
>>> make sense for user mode request.
>>>
>>> So the patch should have used defer proble for direct load only
>>> during booting.
>>
>> What exact guarantees would we be giving to callers if they follow up
>> on probe
>> with -EDEFER_PROBE ? I'd much prefer to try to avoid such uses in init
>> / probe
>> (note that unless you're using async probe since we batch both so it
>> doesn't really
>> matter where you place your code) all together and then for the few
>> remaining
>> stragglers understand the requirements and provide an interface that
>> lets them
>> claim their requirements and try to meets them.
>>
>> A grammatical hunt for drivers who call fw API on init / probe can be
>> completed, although I know the hunt needs a bit more fine tuning it
>> surely can
>> be completed. If we don't have many callers the compexity added for
>> only a
>> few callers with rather loose criteria seems rather unnecessary,
>> specially if
>> we can change the drivers and make these driver sthe exception rather
>> than
>> a norm.
>>
>> Then as for drivers *needing* the fw at probe why not have a proper
>> interface
>> that does guarantee they get the requirements they ask for first ? For
>> instance
>> a new probe type specified by the driver could enable the core to wait
>> for say
>> an event and then tirgger a probe, kind of how we ended up defining
>> the async
>> probe type preference:
>>
>> static struct some_bus_driver some_driver = {
>>          .probe = some_probe,
>>          .id_table = some_id,
>>          .driver = {
>>                  .name = DEVICE_NAME,
>>                  .pm = &some_pm_ops,
>>                  .probe_type = PROBE_PREFER_POST_FOO,
>>          },
>> };
>>
>> Then we just don't try just hoping for completion but rather can do
>> something
>> about the criteria passed.

So should the probe type indicate some event or should it just indicate 
what the driver needs, ie. .probe_type = PROBE_TYPE_NEED_FW.

Regards,
Arend

> That sounds good to me and learning about the async probe type. We do a
> schedule work in our module_init to avoid the probe being done in init
> context. Guess we can change that using the async probe type :-p
>
> Regards,
> Arend
> --
> 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/

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