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

Message-ID: <CO1PR11MB508914851DFC032B7E6A3324D6739@CO1PR11MB5089.namprd11.prod.outlook.com>
Date:   Wed, 24 Aug 2022 18:46:13 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     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>,
        "gospo@...adcom.com" <gospo@...adcom.com>
Subject: RE: [patch net-next v2 4/4] net: devlink: expose the info about
 version representing a component



> -----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.

Thanks,
Jake

> Since we have no use of component flashing now it's all cart
> before the horse.
> 
> Coincidentally I doubt anyone is making serious use of the health
> infrastructure.

There haven't been a lot of implementations here, which makes it hard to develop tooling, and then without tooling no one wants to write the implementation....