netdev - Re: [patch net-next 0/9] mlxsw: Support firmware flash

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:   Sun, 28 May 2017 17:17:35 -0700
From:   Jakub Kicinski <kubakici@...pl>
To:     Yotam Gigi <yotamg@...lanox.com>
Cc:     David Miller <davem@...emloft.net>, <Yuval.Mintz@...ium.com>,
        <jiri@...nulli.us>, <netdev@...r.kernel.org>,
        <idosch@...lanox.com>, <mlxsw@...lanox.com>,
        <bhutchings@...arflare.com>
Subject: Re: [patch net-next 0/9] mlxsw: Support firmware flash

On Sun, 28 May 2017 10:26:49 +0300, Yotam Gigi wrote:
> On 05/23/2017 06:38 PM, David Miller wrote:
> > From: Yotam Gigi <yotamg@...lanox.com>
> > Date: Tue, 23 May 2017 18:14:15 +0300
> >  
> >> Sorry, I am not sure I understand. You think that drivers should not implement
> >> ethtool's flash_device callback anymore? do you have an alternative for firmware
> >> flash?  
> > As stated, export an MTD device.  
> 
> So, after we have been going over MTD, it seems like it does not fit our needs
> at all.
> 
> MTD device provides (erasable-)block access to a flash storage, where in our
> case the firmware burn process is just pouring a binary BLOB into the device.
> The driver is not aware of the internal storage used for storing the firmware as
> it is not defined in our driver-hardware API.
> 
> Needless to say that block access has no meaning in our case, so any solution
> that will involve MTD device to burn our firmware (if there is a solution at
> all) will be a workaround and will not fit MTD purpose.
> 
> Apart for boot time firmware flash, which we have already pushed we would really
> like to allow the user to ask for a specific firmware version. Do you have any
> other solution for us apart from "ethtool -f"?

Could you elaborate on what the requirements are for "allowing users to
ask for a specific firmware version"?  How do the FWs differ?  I'm
asking because we are currently lacking ABI for selecting device
"modes".  Netronome has this problem.  Cavium has recently posted a
patch which used module parameter to flip between "OvS" and "basic NIC"
firmwares.

For Netronome we will definitely want a way to switch between at least
three applications so far - basic, OvS and eBPF - but I also feel like
we shouldn't limit that list, since anyone can write their own FW for
programmable NICs.

I think you were primarily concerned with writing persistent storage so
far.  Does "allowing the user to ask..." means write flash and reboot or
also a runtime switch?  I think we probably need both?

> This problem is even more relevant in the Mellanox HCA driver team, which would
> like to use that code in order to burn the HCA firmware, but not intend to
> trigger it on boot time, which means that must have a way for the user to
> trigger it.

What would the requirements for the HCA team be?  Is it about loading
different code or loading HW settings?