netdev - Re: [RFC PATCH net-next v2 6/6] devlink: add overwrite mode to flash update

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: <20200721100406.67c17ce9@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Tue, 21 Jul 2020 10:04:06 -0700
From:   Jakub Kicinski <kubakici@...pl>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     Jacob Keller <jacob.e.keller@...el.com>, netdev@...r.kernel.org,
        Tom Herbert <tom@...bertland.com>,
        Jiri Pirko <jiri@...lanox.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        Michael Chan <michael.chan@...adcom.com>,
        Bin Luo <luobin9@...wei.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Leon Romanovsky <leon@...nel.org>,
        Ido Schimmel <idosch@...lanox.com>,
        Danielle Ratson <danieller@...lanox.com>
Subject: Re: [RFC PATCH net-next v2 6/6] devlink: add overwrite mode to
 flash update

On Tue, 21 Jul 2020 15:53:56 +0200 Jiri Pirko wrote:
> Mon, Jul 20, 2020 at 05:51:59PM CEST, kubakici@...pl wrote:
> >On Mon, 20 Jul 2020 12:09:53 +0200 Jiri Pirko wrote:  
> >> This looks odd. You have a single image yet you somehow divide it
> >> into "program" and "config" areas. We already have infra in place to
> >> take care of this. See DEVLINK_ATTR_FLASH_UPDATE_COMPONENT.
> >> You should have 2 components:
> >> 1) "program"
> >> 2) "config"
> >> 
> >> Then it is up to the user what he decides to flash.  
> >
> >99.9% of the time users want to flash "all". To achieve "don't flash
> >config" with current infra users would have to flash each component   
> 
> Well you can have multiple component what would overlap:
> 1) "program" + "config" (default)
> 2) "program"
> 3) "config"

Say I have FW component and UNDI driver. Now I'll have 4 components?
fw.prog, fw.config, undi.prog etc? Are those extra ones visible or just
"implied"? If they are visible what version does the config have?

Also (3) - flashing config from one firmware version and program from
another - makes a very limited amount of sense to me.

> >one by one and then omit the one(s) which is config (guessing which 
> >one that is based on the name).
> >
> >Wouldn't this be quite inconvenient?  
> 
> I see it as an extra knob that is actually somehow provides degradation
> of components.

Hm. We have the exact opposite view on the matter. To me components
currently correspond to separate fw/hw entities, that's a very clear
meaning. PHY firmware, management FW, UNDI. Now we would add a
completely orthogonal meaning to the same API. 

Why?

In the name of "field reuse"?

> >In case of MLX is PSID considered config?  
> 
> Nope.