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: <345c4cb7-13a2-ff93-13bb-fc8fbdb9dca0@intel.com>
Date:   Tue, 31 Jan 2023 10:36:00 -0800
From:   Jacob Keller <jacob.e.keller@...el.com>
To:     Michael Walle <michael@...le.cc>,
        "Russell King (Oracle)" <linux@...linux.org.uk>
CC:     Andrew Lunn <andrew@...n.ch>, Jiri Pirko <jiri@...nulli.us>,
        "Jakub Kicinski" <kuba@...nel.org>,
        Heiner Kallweit <hkallweit1@...il.com>,
        <netdev@...r.kernel.org>
Subject: Re: PHY firmware update method



On 1/31/2023 9:48 AM, Michael Walle wrote:
> Am 2023-01-31 17:29, schrieb Russell King (Oracle):
>> On Tue, Jan 31, 2023 at 05:10:08PM +0100, Michael Walle wrote:
>>> Am 2023-01-24 21:42, schrieb Andrew Lunn:
>>>> One device being slow to probe will slow down the probe of that
>>>> bus. But probe of other busses should be unaffected. I _guess_ it
>>>> might have a global affect on EPROBE_DEFER, the next cycle could be
>>>> delayed?  Probably a question for GregKH, or reading the code.
>>>>
>>>> If it going to be really slow, then i would suggest making use of
>>>> devlink and it being a user initiated operation.
>>>
>>> One concern which raised internally was that you'll always do
>>> the update (unconditionally) if there is a newer version. You seem
>>> to make life easier for the user, because the update just runs
>>> automatically. OTHO, what if a user doesn't want to update (for
>>> whatever reason) to the particular version in linux-firmware.git.
>>> I'm undecided on that.
>>
>> On one hand, the user should always be asked whether they want to
>> upgrade the firmware on their systems, but there is the argument
>> about whether a user has sufficient information to make an informed
>> choice about it.
>>
>> Then there's the problem that a newer firmware might introduce a
>> bug, but the user wants to use an older version (which is something
>> I do with some WiFi setups, and it becomes a pain when linux-firmware
>> is maintained by the distro, but you don't want to use that provided
>> version.
>>
>> I really don't like the idea of the kernel automatically updating
>> non-volatile firmware - that sounds to me like a recipe for all
>> sorts of disasters.
> 
> I agree. That leaves us with the devlink solution, right?
> 
> Where would the firmware be stored, fwupd.org was mentioned by
> Jakub, or is it the users responsibility to fetch it from the
> vendor? Andrew was against adding a firmware update mechanism
> without having the binaries.
> 
> -michael

Well devlink flash update is already supported, and typically assumes
you got binaries from somewhere like a vendor website if I understand?

For non volatile firmware I think its the best approach we have currently.

Thanks,
Jake