netdev - Re: [patch net-next v2 4/4] net: devlink: expose the info about version representing a component

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] [day] [month] [year] [list]

Message-ID: <YwaA2hB27VRt6Utg@C02YVCJELVCG.dhcp.broadcom.net>
Date:   Wed, 24 Aug 2022 15:49:46 -0400
From:   Andy Gospodarek <andrew.gospodarek@...adcom.com>
To:     "Keller, Jacob E" <jacob.e.keller@...el.com>
Cc:     Jakub Kicinski <kuba@...nel.org>, Jiri Pirko <jiri@...nulli.us>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "idosch@...dia.com" <idosch@...dia.com>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "saeedm@...dia.com" <saeedm@...dia.com>,
        "vikas.gupta@...adcom.com" <vikas.gupta@...adcom.com>
Subject: Re: [patch net-next v2 4/4] net: devlink: expose the info about
 version representing a component

On Wed, Aug 24, 2022 at 06:46:13PM +0000, Keller, Jacob E wrote:
> 
> 
> > -----Original Message-----
> > From: Jakub Kicinski <kuba@...nel.org>
> > Sent: Wednesday, August 24, 2022 11:12 AM
> > To: Keller, Jacob E <jacob.e.keller@...el.com>
> > Cc: Jiri Pirko <jiri@...nulli.us>; netdev@...r.kernel.org; davem@...emloft.net;
> > idosch@...dia.com; pabeni@...hat.com; edumazet@...gle.com;
> > saeedm@...dia.com; vikas.gupta@...adcom.com; gospo@...adcom.com
> > Subject: Re: [patch net-next v2 4/4] net: devlink: expose the info about version
> > representing a component
> > 
> > On Wed, 24 Aug 2022 17:31:46 +0000 Keller, Jacob E wrote:
> > > > Well, I thought it would be polite to let the user know what component
> > > > he can pass to the kernel. Now, it is try-fail/success game. But if you
> > > > think it is okay to let the user in the doubts, no problem. I will drop
> > > > the patch.
> > >
> > > I would prefer exposing this as well since it lets the user know which names are
> > valid for flashing.
> > >
> > > I do have some patches for ice to support individual component update as well
> > I can post soon.
> > 
> > Gentlemen, I had multiple false starts myself adding information
> > to device info, flashing and health reporters. Adding APIs which
> > will actually be _useful_ in production is not trivial. I have
> > the advantage of being able to talk to Meta's production team first
> > so none of my patches made it to the list.
> > 
> > To be clear I'm not saying (nor believe) that Meta's needs or processes
> > are in any way "the right way to go" or otherwise should dictate
> > the APIs. It's just an example I have direct access to.
> > 
> > I don't think I'm out of line asking you for a clear use case.
> > Just knowing something is flashable is not sufficient information,
> > the user needs to know what the component actually describes and
> > what binary to use to update it.
> > 
> 
> At least for ice, the same binary would be used for individual component update. the PLDM firmware binary header describes where each component is within it, and is decoded by lib/pldmfw, we just need to translate the PLDM header codes to the userspace names.
> 
> The old tools which Intel supports do have support for such an individual component update, but the demand wasn't very high, so I never got around to posting the patches to support this. There are some corner cases where it might be helpful to flash (or reflash) a single component, but it seems somewhat less useful for most end-users and mostly would be useful for internal engineering and debugging.
> 
> Users would still need to know what each component is, and there isn't much the kernel API itself can do here. We do document a short description, but that is going to be limited in usefulness since it likely depends on a lot of related knowledge.
> 

I agree with this.  Individual component updates are most useful in a
dev/debug environment rather than in production.  I'm not sure there is
value in exporting this all the way out to kernel APIs.



Download attachment "smime.p7s" of type "application/pkcs7-signature" (4222 bytes)