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: <20220819145459.1a7c6a61@kernel.org>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ