linux-kernel - 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 16:37:45 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Ariel Elior <aelior@...vell.com>
Cc:     Sudarsana Reddy Kalluru <skalluru@...vell.com>,
        Paul Menzel <pmenzel@...gen.mpg.de>,
        GR-everest-linux-l2 <GR-everest-linux-l2@...vell.com>,
        "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

On Thu, 20 Feb 2020 15:40:37 +0000 Ariel Elior wrote:
> > -----Original Message-----
> > From: Sudarsana Reddy Kalluru <skalluru@...vell.com>
> > Sent: Thursday, February 20, 2020 11:17 AM
> > 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; LKML <linux-kernel@...r.kernel.org>; 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.
> > 
> Hi,
> There are additional reasons why backwards/forwards compatibility considerations
> are not applicable here. This Fw is not nvram based, and does not reside in the
> device. It is programed to the device on every driver load. The driver will
> never face a device "already initialized" with a version of FW it is not
> familiar with.

How do you deal with VFs?

> The device also has traditional management FW in nvram in the device with which
> we have a backwards and forwards compatibility mechanism, which works just
> fine.
> But the FW under discussion is fastpath Fw, used to craft every packet going out
> of the device and analyze and place every packet coming into the device.
> Supporting multiple versions of FW would be tantamount to implementing dozens of
> versions of start_xmit and napi_poll in the driver (not to mention multiple
> fastpath handles of all the offloads the device supports, roce, iscsi, fcoe and
> iwarp, as all of these are offloaded by the FW).
> The entire device initialization sequence also changes significantly from one FW
> version to the Next. All of these differences are abstracted away in the FW
> file, which includes the init sequence and the compiled FW. The amount of
> changes required in driver are very significant when moving from one version to
> the next. Trying to keep all those versions alive concurrently would cause this
> already very large driver to be 20x larger.

All your points are disproved by all the devices which have drivers
upstream and don't break backward compatibility on every release.

> We don't have a method of keeping the device operational if the kernel was
> upgraded but firmware tree was not updated. The best that can be done is report
> the problem, which is what we do.