linux-kernel - Re: [PATCH] firmware: wake all waiters

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:   Tue, 27 Jun 2017 13:24:18 -0700
From:   "Luis R. Rodriguez" <mcgrof@...nel.org>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>
Cc:     Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Ming Lei <ming.lei@...hat.com>,
        "Li, Yi" <yi1.li@...ux.intel.com>,
        "AKASHI, Takahiro" <takahiro.akashi@...aro.org>, nbroeking@...com,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Martin Fuzzey <mfuzzey@...keon.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Daniel Wagner <wagi@...om.org>,
        David Woodhouse <dwmw2@...radead.org>,
        jewalt@...innovations.com, rafal@...ecki.pl,
        Arend van Spriel <arend.vanspriel@...adcom.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>, atull@...nel.org,
        Moritz Fischer <moritz.fischer@...us.com>,
        Petr Mladek <pmladek@...e.com>,
        Johannes Berg <johannes.berg@...el.com>,
        Emmanuel Grumbach <emmanuel.grumbach@...el.com>,
        Luca Coelho <luciano.coelho@...el.com>,
        Andy Lutomirski <luto@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Kees Cook <keescook@...omium.org>,
        David Howells <dhowells@...hat.com>,
        Peter Jones <pjones@...hat.com>,
        Hans de Goede <hdegoede@...hat.com>,
        Alan Cox <alan@...ux.intel.com>,
        "Theodore Ts'o" <tytso@....edu>,
        Paul Gortmaker <paul.gortmaker@...driver.com>,
        mtosatti@...hat.com, Matthew Wilcox <mawilcox@...rosoft.com>,
        Stephen Boyd <stephen.boyd@...aro.org>,
        Vikram Mulukutla <markivx@...eaurora.org>,
        lkml <linux-kernel@...r.kernel.org>, oss-drivers@...ronome.com
Subject: Re: [PATCH] firmware: wake all waiters

On Tue, Jun 27, 2017 at 12:52 PM, Bjorn Andersson
<bjorn.andersson@...aro.org> wrote:
> On Tue 27 Jun 12:08 PDT 2017, Luis R. Rodriguez wrote:
>> On Tue, Jun 27, 2017 at 11:59:15AM -0700, Bjorn Andersson wrote:
>> > Are you saying that each kernel driver should be written so that it will
>> > either do direct loading or use firmwared?
>>
>> Hell No! You can fork firmwared or use whatever the hell bin-foo you want.
>> Even if its proprietary and glued with evil rainbow unicorns on it.  The dual
>> mode, best-effort mode and final-mode devices it implemented are key to what
>> you want to mimic as an example to achieve the goal in question.
>>
>
> I'm sorry but your language is totally inappropriate and the reason why
> I tend to stay away from firmware-related discussions.

I'm sorry if I offended you, the goal here was to use an exaggerated
example of what anyone could use to draw in firmware into the kernel.

>> Please give that thought / architecture solution a spin and let me know if
>> it suffices for your needs.
>>
>
> Which solution do you refer to here?

The model of a best-effort and final-mode.

> But as I said, in my view, the decision of making the kernel depend on a
> user space firmware loading mechanism or direct loading should be that
> of the system designer - not the kernel.

You get that freedom today. The fallback mechanism *allows* files to
be fetched in whatever way possible, by issuing a uevent, its up to
userspace to figure out how to gather that and toss it back into the
kernel using the sysfs interface. The firemward daemon is nothing but
an example *new* daemon which uses a model to address the rootfs /
pivot root dilema, as only userspace can know when userspace *is
ready*.

So its not clear to me yet what your grudge with using firmwared with
this new model is exactly. Are you saying you want to *require* the
fallback mechanism from the start, so just skipping the direct FS
lookup ? That would be a new feature request, and we can certainly
consider it, but I'll need Greg to clue me in first on how he'd prefer
an API evolution for new features.

 Luis