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]

Date:   Wed, 22 Jul 2020 09:52:28 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     "Keller, Jacob E" <jacob.e.keller@...el.com>
Cc:     Jiri Pirko <jiri@...nulli.us>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Tom Herbert <tom@...bertland.com>,
        Jiri Pirko <jiri@...lanox.com>,
        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 Wed, 22 Jul 2020 15:30:05 +0000 Keller, Jacob E wrote:
> > >> >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.  
> > 
> > I understand. My concern is, we would have a component with some
> > "subparts". Now it is some fuzzy vagely defined "config part",
> > in the future it might be something else. That is what I'm concerned
> > about. Components have clear api.
> > 
> > So perhaps we can introduce something like "component mask", which would
> > allow to flash only part of the component. That is basically what Jacob
> > has, I would just like to have it well defined.
> 
> So, we could make this selection a series of masked bits instead of a
> single enumeration value.

I'd still argue that components (as defined in devlink info) and config
are pretty orthogonal. In my experience config is stored in its own
section of the flash, and some of the knobs are in no obvious way
associated with components (used by components).

That said, if we rename the "component mask" to "update mask" that's
fine with me.

Then we'd have

bit 0 - don't overwrite config
bit 1 - don't overwrite identifiers

? 

Let's define a bit for "don't update program" when we actually need it.