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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 24 Jan 2023 14:28:43 -0800
From:   Jacob Keller <jacob.e.keller@...el.com>
To:     Michael Walle <michael@...le.cc>, Andrew Lunn <andrew@...n.ch>
CC:     Jiri Pirko <jiri@...nulli.us>, Jakub Kicinski <kuba@...nel.org>,
        "Heiner Kallweit" <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>, <netdev@...r.kernel.org>
Subject: Re: PHY firmware update method



On 1/24/2023 9:11 AM, Michael Walle wrote:
> [sorry for the very late response, but I was working on getting an
> acceptable license for the PHY binary in the meantime]
> 
>>> 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?
> 
> In my case, the firmware binary blob has some static offset to get
> firmware version (I need to double check that one with the vendor).
> Of course we could put that PLDM thingy around it. But it seems we are
> mangling with the binary provided by the vendor before putting it into
> linux-firmware.git. If I understand Jacob correct, Intel will already
> provide the binaries in PLDM format.

Correct, we ship the firmware binaries already in PLDM format, but it
*is* more or less just a header that gets added ahead of the 3 binaries.
(the header points to where in the full binary file each actual firmware
binary data is located, so we can combine all of our images, i.e. the
main NVM firmware, the UEFI firmware, and our netlist firmware)

> 
> Another problem I see is how we can determine if a firmware update
> is possible at all - or if we just try it anyway if that is possible.
> In my case there is already an integrated firmware and the external
> flash is optional. The PHY will try to boot from external flash and
> fall back to the internal one. AFAIK you can read out where the PHY
> was booted from. If the external flash is empty, you cannot detect if
> you could update the firmware.
> 
> So if you'd do this during the PHY probe, it might try to update the
> firmware on every boot and fail. Would that be acceptable?
> 

Wouldn't you just want to update when user requests and have info report
something if it can't figure out what version?

> How long could can a firmware update during probe run? Do we need
> to do it in the background with the PHY being offline. Sounds like
> not something we want.
> 
> -michael

I'm not sure. Since the firmware is loaded from flash I would not expect
to need to download it every probe. I would only expect that if the
firmware had to be loaded each time and wasn't maintained across resets.

For example the ice hardware has some data we load that does not get
saved to flash and we must load that after every probe or reset.