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: <20150902185842.GC8051@wotan.suse.de>
Date:	Wed, 2 Sep 2015 20:58:42 +0200
From:	"Luis R. Rodriguez" <mcgrof@...e.com>
To:	Arend van Spriel <arend@...adcom.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Ming Lei <ming.lei@...onical.com>, 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>,
	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 Wed, Sep 02, 2015 at 02:13:49PM +0200, Arend van Spriel wrote:
> 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.

Right so this is an open question. I suggested something like the above
since the deferred probe documentation on drivers/base/dd.c states:

 * Sometimes driver probe order matters, but the kernel doesn't always have     
 * dependency information 

I'm alluding that we consider *avoiding* -EPROBE_DEFER for areas of the
kernel where some work can be done to not only list the dependency
the information from the driver but also we know we can get it from
the kernel. In this case I do believe we could not only express the
requirement but also wait for it in the kernel. Before we do that
though I think it'd be good to do a grammar hunt to determine exactly
how popular all this fw on probe needed really is.

Greg, provided we find sufficient drivers that really do need firmware
on probe, any thoughts on this line of approach to address this?

  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/