netdev - RE: [EXT] Re: bnx2x: Latest firmware requirement breaks no regression policy

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, 20 Feb 2020 09:17:14 +0000
From:   Sudarsana Reddy Kalluru <skalluru@...vell.com>
To:     Paul Menzel <pmenzel@...gen.mpg.de>,
        Ariel Elior <aelior@...vell.com>,
        GR-everest-linux-l2 <GR-everest-linux-l2@...vell.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "it+linux-netdev@...gen.mpg.de" <it+linux-netdev@...gen.mpg.de>,
        "David S. Miller" <davem@...emloft.net>
Subject: RE: [EXT] Re: bnx2x: Latest firmware requirement breaks no regression
 policy

Hi Paul,
    Bnx2x driver and the storm FW are tightly coupled, and the info is exchanged between them via shmem (i.e., common structures which might change between the releases). Also, FW provides some offset addresses to the driver which could change between the FW releases, following is one such commit,
	https://www.spinics.net/lists/netdev/msg609889.html
Hence it's not very straight forward to provide the backward compatibility i.e., newer (updated) kernel driver with the older FW.
Currently we don’t have plans to implement the new model mentioned below.

Thanks,
Sudarsana
> -----Original Message-----
> From: Paul Menzel <pmenzel@...gen.mpg.de>
> Sent: Wednesday, February 19, 2020 6:14 PM
> To: Sudarsana Reddy Kalluru <skalluru@...vell.com>; Ariel Elior
> <aelior@...vell.com>; GR-everest-linux-l2 <GR-everest-linux-
> l2@...vell.com>
> Cc: netdev@...r.kernel.org; LKML <linux-kernel@...r.kernel.org>; it+linux-
> netdev@...gen.mpg.de; David S. Miller <davem@...emloft.net>
> Subject: [EXT] Re: bnx2x: Latest firmware requirement breaks no regression
> policy
> 
> External Email
> 
> ----------------------------------------------------------------------
> Dear Sudarsana,
> 
> 
> Thank you for your reply.
> 
> 
> On 2020-02-19 09:49, Sudarsana Reddy Kalluru wrote:
> 
> > The firmware file referred below (i.e., storm FW) should be present
> > on the host (i.e., /lib/firmware/bnx2x/ path), not the device. Driver
> > must require this version of the FW to initialize the device, and
> > hence provide the network functionality. Also, the driver is not
> > backward compatible with older FW versions.
> >
> > So it's not possible to handle the below error scenario in the driver,
> >
> > 	>     bnx2x 0000:41:00.0: Direct firmware load for bnx2x/bnx2x-e1h-
> 7.13.11.0.fw failed with error -2
> > 	>     bnx2x: [bnx2x_init_firmware:13557(net02)]Can't load firmware file
> bnx2x/bnx2x-e1h-7.13.11.0.fw
> >
> > At the most, we can validate the existence of FW file on the host
> > during the kernel build or installation.
> 
> That is what I thought about the current state. But why was this
> design decision made? It’s not user-friendly, and as written breaks
> the no regression policy. Users can update the Linux kernel without
> any regressions, and everything working as before. Dave, what is
> your opinion?
> 
> Where are the driver requirements/implementation short-comings
> documented?
> 
> If an older Linux kernel works with a certain firmware version, why
> shouldn’t a newer Linux kernel work with that firmware version.
> Maybe some features are missing, but at least I should get the same
> state as with the older version.
> 
> Do you have plans to switch the driver to a model, where the
> features/requirements of the firmware are queried by the driver, so
> older versions can be supported?
> 
> > FW image name from driver sources:
> > 	drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:
> > 	#define FW_FILE_NAME_E1         "bnx2x/bnx2x-e1-" FW_FILE_VERSION
> ".fw"
> > 	#define FW_FILE_NAME_E1H        "bnx2x/bnx2x-e1h-"
> FW_FILE_VERSION ".fw"
> > 	#define FW_FILE_NAME_E2         "bnx2x/bnx2x-e2-" FW_FILE_VERSION
> ".fw"
> > FW image path on the host:
> > 	/lib/firmware/bnx2x/bnx2x-e1h-7.13.11.0.fw
> Yes, that is what I found in my original research, and that is how
> we fixed it, but with the non-working interface it was more work
> than necessary.
> 
> 
> Kind regards,
> 
> Paul