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 15:39:50 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     "Luis R. Rodriguez" <mcgrof@...nel.org>
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>, yi1.li@...ux.intel.com,
        takahiro.akashi@...aro.org, nbroeking@...com,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        mfuzzey@...keon.com, ebiederm@...ssion.com,
        dmitry.torokhov@...il.com, dwmw2@...radead.org,
        jewalt@...innovations.com, rafal@...ecki.pl, rjw@...ysocki.net,
        atull@...nel.org, moritz.fischer@...us.com, pmladek@...e.com,
        johannes.berg@...el.com, emmanuel.grumbach@...el.com,
        luciano.coelho@...el.com, luto@...nel.org,
        torvalds@...ux-foundation.org, keescook@...omium.org,
        dhowells@...hat.com, pjones@...hat.com, hdegoede@...hat.com,
        alan@...ux.intel.com, tytso@....edu, paul.gortmaker@...driver.com,
        mtosatti@...hat.com, mawilcox@...rosoft.com,
        stephen.boyd@...aro.org, markivx@...eaurora.org,
        linux-kernel@...r.kernel.org, oss-drivers@...ronome.com
Subject: Re: [PATCH] firmware: wake all waiters

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.)

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...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ