netdev - RE: PHY firmware update method

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CO1PR11MB508991C08616EC6AF8CC236CD6569@CO1PR11MB5089.namprd11.prod.outlook.com>
Date:   Fri, 30 Sep 2022 16:49:44 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>
CC:     Jiri Pirko <jiri@...nulli.us>, Michael Walle <michael@...le.cc>,
        "Heiner Kallweit" <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: PHY firmware update method



> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Friday, September 30, 2022 7:46 AM
> To: Andrew Lunn <andrew@...n.ch>; Keller, Jacob E <jacob.e.keller@...el.com>
> Cc: Jiri Pirko <jiri@...nulli.us>; Michael Walle <michael@...le.cc>; Heiner
> Kallweit <hkallweit1@...il.com>; Russell King <linux@...linux.org.uk>;
> netdev@...r.kernel.org
> Subject: Re: PHY firmware update method
> 
> On Fri, 30 Sep 2022 14:36:47 +0200 Andrew Lunn wrote:
> > > Yeah, I tend to agree here. I believe that phylib should probably find a
> > > separate way to to the flash.
> > >
> > > But perhaps it could be a non-user-facing flash. I mean, what if phylib
> > > has internal routine to:
> > > 1) do query phy fw version
> > > 2) load a fw bin related for this phy (easy phy driver may provide the
> > > 				       path/name of the file)
> > > 3) flash if there is a newer version available
> >
> > That was my first suggestion. One problem is getting the version from
> > the binary blob firmware. But this seems like a generic problem for
> > linux-firmware, so maybe somebody has worked on a standardised header
> > which can be preppended with this meta data?
> 
> Not that I know, perhaps the folks that do laptop FW upgrade have some
> thoughts https://fwupd.org/
> 
> Actually maybe there's something in DMTF, does PLDM have standard image
> format? Adding Jake. Not sure if PHYs would use it tho :S
> 

PLDM for Firmware does indeed specify a standardized header for binary images and could be used for PHY firmware. The PLDM header itself describes things as components, where each component gets a record which indicates the version of that component and where in the binary that component exists. Then there are a series of records which determine which sets of components go together and for which devices. I don't think the ice firmware files use the full standard as they always have only a single device record, though the lib/pldmfw codes does try to allow the more expressive ability to support multiple device types from a single binary. Specifying a PHY component would be possible, and you could fairly easily prepend a PLDM firmware header on top of an arbitrary binary.

Thanks,
Jake

> What's the interface that the PHY FW exposes? Ben H was of the opinion
> that we should just expose the raw mtd devices.. just saying..