netdev - Re: [patch net-next 4/4] net: devlink: expose default flash update target

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:   Fri, 19 Aug 2022 14:54:59 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, idosch@...dia.com,
        pabeni@...hat.com, edumazet@...gle.com, saeedm@...dia.com,
        jacob.e.keller@...el.com, vikas.gupta@...adcom.com,
        gospo@...adcom.com
Subject: Re: [patch net-next 4/4] net: devlink: expose default flash update
 target

On Fri, 19 Aug 2022 10:12:16 +0200 Jiri Pirko wrote:
> Fri, Aug 19, 2022 at 04:53:01AM CEST, kuba@...nel.org wrote:
> >On Thu, 18 Aug 2022 15:00:42 +0200 Jiri Pirko wrote:  
> >> Allow driver to mark certain version obtained by info_get() op as
> >> "flash update default". Expose this information to user which allows him
> >> to understand what version is going to be affected if he does flash
> >> update without specifying the component. Implement this in netdevsim.  
> >
> >My intuition would be that if you specify no component you're flashing
> >the entire device. Is that insufficient? Can you explain the use case?  
> 
> I guess that it up to the driver implementation. I can imagine arguments
> for both ways. Anyway, there is no way to restrict this in kernel, so
> let that up to the driver.

To be clear - your intent is to impose more structure on the relation
between the dev info and dev flash, right? But just "to be safe",
there's no immediate need to do this?

The entire dev info / dev flash interface was driven by practical needs
of the fleet management team @Facebook / Meta.

What would make the changes you're making more useful here would be if
instead of declaring the "default" component, we declared "overall"
component. I.e. the component which is guaranteed to encompass all the
other versions in "stored", and coincidentally is also the default
flashed one.

That way the FW version reporting can be simplified to store only one
version.