netdev - RE: [EXT] Re: [PATCH net-next 1/2] bnx2x: Utilize firmware 7.13.20.0

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:   Mon, 8 Nov 2021 15:44:07 +0000
From:   Ariel Elior <aelior@...vell.com>
To:     Andrew Lunn <andrew@...n.ch>, Manish Chopra <manishc@...vell.com>
CC:     Jakub Kicinski <kuba@...nel.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Sudarsana Reddy Kalluru <skalluru@...vell.com>,
        "malin1024@...il.com" <malin1024@...il.com>,
        Shai Malin <smalin@...vell.com>,
        Omkar Kulkarni <okulkarni@...vell.com>,
        Nilesh Javali <njavali@...vell.com>,
        "GR-everest-linux-l2@...vell.com" <GR-everest-linux-l2@...vell.com>
Subject: RE: [EXT] Re: [PATCH net-next 1/2] bnx2x: Utilize firmware 7.13.20.0

> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Sent: Monday, November 8, 2021 3:45 PM
> To: Manish Chopra <manishc@...vell.com>
> Cc: Ariel Elior <aelior@...vell.com>; Jakub Kicinski <kuba@...nel.org>; Greg
> KH <gregkh@...uxfoundation.org>; netdev@...r.kernel.org;
> stable@...r.kernel.org; Sudarsana Reddy Kalluru <skalluru@...vell.com>;
> malin1024@...il.com; Shai Malin <smalin@...vell.com>; Omkar Kulkarni
> <okulkarni@...vell.com>; Nilesh Javali <njavali@...vell.com>; GR-everest-
> linux-l2@...vell.com
> Subject: Re: [EXT] Re: [PATCH net-next 1/2] bnx2x: Utilize firmware 7.13.20.0
> 
> I'm i right in says, the bad firmware was introduced with:
Correct.

> commit 0a6890b9b4df89a83678eba0bee3541bcca8753c
> Author: Sudarsana Reddy Kalluru <skalluru@...vell.com>
> Date:   Mon Nov 4 21:51:09 2019 -0800
> 
>     bnx2x: Utilize FW 7.13.15.0.
> 
>     Commit 97a27d6d6e8d "bnx2x: Add FW 7.13.15.0" added said .bin FW to
>     linux-firmware tree. This FW addresses few important issues in the earlier
>     FW release.
>     This patch incorporates FW 7.13.15.0 in the bnx2x driver.
> 
> And that means v5.5 through to at least 5.16 will be broken? It has
> been broken for a little under 2 years? And both 5.10 and 5.15 are
> LTS. And you don't care.You will leave them broken, even knowing that
> distribution kernels are going to use these LTS kernel?
Not Correct. We would like to solve the problem here too. But what we plan
is to push these fixes upstream and to any other distro which will take them.
We did not face difficulties in the past to have the distros include the newer
FW files which the driver required.

> 
> And you could of avoided this by not breaking the firmware ABI. Which
> you now say is actually possible. And after being broken for 2 years
> it is now time critical?
It is not correct that this would have been avoided by not Breaking the ABI.
The breakage was a bug introduced in the FW for SR-IOV. Having
backwards/forwards compatible ABI would not change the fact that the bug
would be there. The bug is only exposed with old VM running on new
Hypervisor, so it is not correct to say "bug was there for 2 years".
Although problem was introduced 2 years ago, it was exposed now, and now
we want to fix it. Whether the fix is done in a manner by which driver
can work with old FW file on disk or not is not related to the problem itself.

I stand by that *generally* this HW architecture is not designed for
backward/forward compatibility with regard to this FW. But it is true that in
this case it can be done. Numerous FW versions of this device which were already
accepted and all were non backwards compatible and all had this same issue
(updating driver mandates syncing up to latest FW tree, otherwise driver load
gracefully fails). Since this is the last FW we are pushing for this EOLing
device it seems a bit meticulous to insist on this for this (hopefully) last
version of the device FW. If community insists, we will provide it in backwards
compatible manner (since it so happens that in this version it is possible), but
it may take us some time to prepare that. That may increase the exposure of the
SR-IOV bug to further distros which may pick up the older FW/Driver combination
in that time.
> 
> 
>     Andrew