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]
Message-ID: <8daadcd1-3ff2-2448-7957-827a71ae4d2e@molgen.mpg.de>
Date:   Wed, 19 Feb 2020 13:43:48 +0100
From:   Paul Menzel <pmenzel@...gen.mpg.de>
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" <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        it+linux-netdev@...gen.mpg.de,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: bnx2x: Latest firmware requirement breaks no regression policy

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


Download attachment "smime.p7s" of type "application/pkcs7-signature" (5174 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ