linux-kernel - Re: [PATCH v2 1/8] firmware: add new extensible firmware API

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]

Date:	Thu, 11 Aug 2016 14:15:31 -0700
From:	Bjorn Andersson <bjorn.andersson@...aro.org>
To:	"Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:	Ming Lei <ming.lei@...onical.com>,
	Andrew Morton <akpm@...ux-foundation.org>, mmarek@...e.com,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, bp@...en8.de,
	chunkeey@...glemail.com, lkml <linux-kernel@...r.kernel.org>,
	markivx@...eaurora.org, Stephen Boyd <stephen.boyd@...aro.org>,
	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	Mark Brown <broonie@...nel.org>, tiwai@...e.de,
	johannes@...solutions.net, hauke@...ke-m.de,
	jwboyer@...oraproject.org,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Jiri Slaby <jslaby@...e.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andy Lutomirski <luto@...capital.net>, fengguang.wu@...el.com,
	Richard Purdie <rpurdie@...ys.net>, ki@...sung.com,
	Abhay_Salunke@...l.com, Julia Lawall <Julia.Lawall@...6.fr>,
	Gilles.Muller@...6.fr, nicolas.palix@...g.fr, teg@...m.no,
	David Howells <dhowells@...hat.com>,
	Kees Cook <keescook@...omium.org>, tj@...nel.org,
	daniel.vetter@...ll.ch, Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH v2 1/8] firmware: add new extensible firmware API - sysdata_file_request*()

On Thu, Jun 16, 2016 at 4:59 PM, Luis R. Rodriguez <mcgrof@...nel.org> wrote:
> The firmware API has evolved over the years slowly, as it
> grows we extend it by adding new routines or at times we extend
> existing routines with more or less arguments. This doesn't scale
> well, when new arguments are added to existing routines it means
> we need to traverse the kernel with a slew of collateral
> evolutions to adjust old driver users. The firmware API is also
> now being used for things outside of the scope of what typically
> would be considered "firmware", an example here is the p54 driver
> enables users to provide a custom EEPROM through this interface.
> Another example is optional CPU microcode updates. This list is
> actually quite endless...
>

Why can't this done in an incremental fashion, like other frameworks
has done, by transitioning the existing APIs to take a argument
structure?

How are these cases of "misuse" going to go away with the introduction
of another non-firmware-loading interface?

> There are other subsystems which would like to make use of the
> APIs for similar things (not firmware) but have different
> requirements and criteria which they'd like to be met for the
> requested file. If different requirements are needed it would
> again mean adding more arguments and making a slew of collateral
> evolutions, or adding yet-another-new-API-call.
>

Is the main problem here that it's named "firmware" or that there are
potential requirements that are inconsistent with something loading
"firmware"?

[..]
>
>  - Usermode helpers is completely ignored, *always*

What technical benefit does this give us?


As discussed elsewhere, having a mechanism for postponing firmware
loading until the appropriate file systems are mounted would remove my
dependency on the usermode helper. But the direction discussed would
be unrelated to firmware vs sysdata.

Regards,
Bjorn