netdev - Re: [PATCH net-next 1/2] devlink: add fw bank select parameter

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: <20221206174136.19af0e7e@kernel.org>
Date:   Tue, 6 Dec 2022 17:41:36 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Shannon Nelson <shannon.nelson@....com>
Cc:     <netdev@...r.kernel.org>, <davem@...emloft.net>, <jiri@...dia.com>
Subject: Re: [PATCH net-next 1/2] devlink: add fw bank select parameter

On Mon, 5 Dec 2022 09:26:26 -0800 Shannon Nelson wrote:
> Some devices have multiple memory banks that can be used to
> hold various firmware versions that can be chosen for booting.
> This can be used in addition to or along with the FW_LOAD_POLICY
> parameter, depending on the capabilities of the particular
> device.
> 
> This is a parameter suggested by Jake in
> https://lore.kernel.org/netdev/CO1PR11MB508942BE965E63893DE9B86AD6129@CO1PR11MB5089.namprd11.prod.outlook.com/

Can we make this netlink attributes? 

What is the flow that you have in mind end to end (user actions)?
I think we should document that, by which I mean extend the pseudo 
code here:

https://docs.kernel.org/next/networking/devlink/devlink-flash.html#firmware-version-management

I expect we need to define the behavior such that the user can ignore
the banks by default and get the right behavior.

Let's define
 - current bank - the bank from which the currently running image has
   been loaded
 - active bank - the bank selected for next boot
 - next bank - current bank + 1 mod count

If we want to keep backward compat - if no bank specified for flashing:
 - we flash to "next bank"
 - if flashing is successful we switch "active bank" to "next bank"
not that multiple flashing operations without activation/reboot will
result in overwriting the same "next bank" preventing us from flashing
multiple banks without trying if they work..

"stored" versions in devlink info display the versions for "active bank"
while running display running (i.e. in RAM, not in the banks!)

In terms of modifications to the algo in documentation:
 - the check for "stored" versions check should be changed to an while
   loop that iterates over all banks
 - flashing can actually depend on the defaults as described above so
   no change

We can expose the "current" and "active" bank as netlink attrs in dev
info.