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]

Message-ID: <20220820131115.35dc83ee@kernel.org>
Date:   Sat, 20 Aug 2022 13:11:15 -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 Sat, 20 Aug 2022 07:44:41 +0200 Jiri Pirko wrote:
> >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.  
> 
> It is just semantics.

You say that like it's a synonym for irrelevance. Semantics are
*everything* for the uAPI :)

> Default is what we have now and drivers are using
> it. How, that is up to the driver. I see no way how to enforce this, do
> you?

Not sure I understand. We document the thing clearly as "this is the
overall and must include all parts of stored FW", name it appropriately.
If someone sneaks in code which abuses the value for something else,
nothing we can do, like with every driver API we have.

The "default" gives user information but to interpret that information
user is presupposed to know the semantics of the components. Of what
use is knowing that default is component A if I don't know that it's
the component I want to flash. And if so why don't I just say
"component A"?

> But anyway, I can split the patchset in 2:
> 1) sanitize components
> 2) default/overall/whatever
> If that would help.

Sure thing, seems like a practical approach.

On second thought the overall may not be practical, there are sometimes
critical components on the board you don't really want to flash unless
you really have to. CPLDs and stuff. So perhaps we should scratch (2)
altogether until we have a clear need...