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 16:50:59 -0700
From:   "Luis R. Rodriguez" <mcgrof@...nel.org>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Arend Van Spriel <arend.vanspriel@...adcom.com>,
        Tom Gundersen <teg@...m.no>, Daniel Wagner <wagi@...om.org>,
        Ming Lei <ming.lei@...hat.com>,
        "Li, Yi" <yi1.li@...ux.intel.com>,
        "AKASHI, Takahiro" <takahiro.akashi@...aro.org>,
        Nicolas Broeking <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>,
        David Woodhouse <dwmw2@...radead.org>,
        jewalt@...innovations.com, rafal@...ecki.pl,
        "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>,
        Luciano 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>, Tso Ted <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>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        oss-drivers@...ronome.com
Subject: Re: [PATCH] firmware: wake all waiters

On Tue, Jun 27, 2017 at 3:39 PM, Jakub Kicinski
<jakub.kicinski@...ronome.com> wrote:
> On Wed, 28 Jun 2017 00:24:19 +0200, Luis R. Rodriguez wrote:
>> On Tue, Jun 27, 2017 at 02:25:53PM -0700, Jakub Kicinski wrote:
>> > On Tue, 27 Jun 2017 18:39:42 +0200, Luis R. Rodriguez wrote:
>> > >
>> > > > The problem is that advanced NICs are quite programmable [1] and
>> > > > depending on use case one may want to load different firmware files.
>> > >
>> > > Right, so in the 802.11 world some devices might use different firmware for
>> > > different modes of operation, STA, AP, Mesh, but this is all very protocol
>> > > specific, so userspace could tickle the kernel about a mode.
>> > >
>> > > Do your use cases have protocol definitions which can be exposed in userspace?
>> > > Or are these just fw variants with different bells and whistles? How man
>> > > different use cases are we talking about?
>> >
>> > Right now we have three modes that come from Netronome itself, a "basic
>> > NIC" one, and two advanced for TC flower/Open vSwitch acceleration and
>> > for eBPF offload.  I was hoping some enumeration scheme could work here,
>> > but I really can't come up with one.
>>
>> How about just supporting 3 firmware names, with the first two being optional,
>> but if found one of those two is found it would use that one. Then only if
>> both of these are not present would a default be looked for and used?
>>
>> In terms of interface, a simple symlink / renaming scheme would suffice to
>> support this. No custom hooks at all.
>
> That's what we do today as a stop-gap solution :)  (BTW mkinitrd
> doesn't seem to like symlinks so I use hard links.)

I see only 1 request_firmware() request on your driver and its not optional?

What I was suggesting was have 3 separate requests. Two optional files
which you hunt for first, and if either of them are present you use
them. If both are missing you go with the default.

> The issue is if you have two identical cards, how to load different FW
> on them?  We would have to encode the serial number into the firmware
> name or the pci_name() at least.  The nice thing about this solution is
> that it requires almost zero code on the kernel size...  hm...

Yeah, that could work -- ie, for each of the 3 mode firmware you
actually *first* look for the pci_name() derivative first, if any of
them is found use that. Otherwise you then move on to the non
pci_name() varaints with the same logic. The last one would be the
default Fisher-Price® one.

Anyway -- I still think *long term* this is best ironed out by
identifying the modes and seeing if perhaps networking folks might
come to some agreement on these as different modes, then your driver
can have respective hooks for the different modes based on some user
specified mode flip or requirement.

If this is not possible... a sysfs know interface is always possible.

 Luis