linux-kernel - Re: [RFC] firmware: annotate thou shalt not request fw on init or probe

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 3 Sep 2015 03:35:33 +0200
From:	"Luis R. Rodriguez" <mcgrof@...e.com>
To:	Julia Lawall <julia.lawall@...6.fr>
Cc:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>,
	ming.lei@...onical.com, torvalds@...ux-foundation.org,
	liam.r.girdwood@...ux.intel.com, yang.jie@...el.com, tiwai@...e.de,
	dmitry.torokhov@...il.com, joonas.lahtinen@...ux.intel.com,
	teg@...m.no, viro@...iv.linux.org.uk, gregkh@...uxfoundation.org,
	kay@...y.org, dwmw2@...radead.org, linux-kernel@...r.kernel.org,
	yalin.wang2010@...il.com, Jonathan Corbet <corbet@....net>,
	Gilles Muller <Gilles.Muller@...6.fr>,
	Nicolas Palix <nicolas.palix@...g.fr>,
	Michal Marek <mmarek@...e.com>, linux-doc@...r.kernel.org,
	cocci@...teme.lip6.fr, Alessandro Rubini <rubini@...dd.com>,
	Kevin Cernekee <cernekee@...il.com>,
	Jiri Slaby <jslaby@...e.com>, linux-serial@...r.kernel.org,
	Arend Van Spriel <arend@...adcom.com>
Subject: Re: [RFC] firmware: annotate thou shalt not request fw on init or
 probe

On Sat, Aug 29, 2015 at 06:18:20PM +0200, Julia Lawall wrote:
> > +@ defines_module_init exists @
> > +declarer name module_init;
> > +identifier init;
> > +@@
> > +
> > +module_init(init);
> > +
> > +@ has_probe depends on defines_module_init @
> > +identifier drv_calls, drv_probe;
> > +type bus_driver;
> > +identifier probe_op =~ "(probe)";
> > +@@
> > +
> > +bus_driver drv_calls = {
> > +	.probe_op = drv_probe,
> > +};
> 
> I'm not sure that this is enough.  For example, there is the macro
> platform_driver_probe that initializes probe fields.  There is likewise
> module_platform_driver, which is a top-level declaration that encapsulates
> the module_init and the definition of the module_init function, which in
> turn calls platform_driver_probe.  There is also module_platform_driver,
> which encapsulates the module_init, but not the initialization of the probe
> field.  Are you concerned with any of these cases?

Yes, and also it would seem this would only capture simple one level of
routine indirection, for instance if probe called bar() and it was within
bar() that the driver code called a fw request call, that would not be picked
up, correct?

If true then the hunt is yet even more complex. The discussion that prompted me
to send this is still unfolding though [0] and it seems we may want to allow
for these type of calls within probe in the end but in order to vet for drivers
that fw is available through the direct filesystem lookup we may need help from
userspace. As that discussion unfolds it will be good to keep in mind what
effort we'd need to hunt all users down for now.

[0] http://lkml.kernel.org/r/CAB=NE6UBRa0K7=PomJzKxsoj4GzAqkYrkp=O+UfVvu2fwM25pA@mail.gmail.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/