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]

Message-ID: <ced75f7f596a146b58b87dd2d6bad210@walle.cc>
Date:   Tue, 24 Jan 2023 18:11:07 +0100
From:   Michael Walle <michael@...le.cc>
To:     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,
        Keller Jacob E <jacob.e.keller@...el.com>
Subject: Re: PHY firmware update method

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

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?

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