linux-kernel - Re: [PATCH 2/4] usb: typec: tipd: add function to request firmware

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:   Fri, 8 Dec 2023 19:58:52 +0100
From:   Javier Carrasco <javier.carrasco@...fvision.net>
To:     Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] usb: typec: tipd: add function to request firmware

Hi Heikki,

On 08.12.23 15:55, Heikki Krogerus wrote:

>> +	ret = request_firmware(fw, firmware_name, tps->dev);
>> +	if (ret) {
>> +		dev_err(tps->dev, "failed to retrieve \"%s\"\n", firmware_name);
>> +		/* probe deferring in case the file system is not ready */
>> +		return (ret == -ENOENT) ? -EPROBE_DEFER : ret;
> 
> It's more likely that the firmware really isn't available, and it will
> never be available in this case. I think there is only one place in
> kernel where failing request_firmware() can lead to deferred probe
> (drivers/tee/optee/smc_abi.c) and there the code can actually see the
> system state - that's actually the condition.
> 
> So just return dev_err_probe() here:
> 
> 	ret = request_firmware(fw, firmware_name, tps->dev);
> 	if (ret)
>                 return dev_err_probe(tps->dev, ret, "failed to retrieve \"%s\"", firmware_name);
> 
Thank you for your feedback.

This solution arose from a real use case: in the system I am using to
test the tps65987d, the filesystem is not ready when the probe function
is called. If I just return on -ENOENT, the device will never get the
update.

Note that we are only triggering the update if the device is in patch
mode, so a firmware will be expected for the device to run and reach the
app mode.
In that case deferring the probe and keeping on trying to make the
update makes sense because otherwise the device will not be able to
offer its functionality. If the device is not in patch mode, no update
will be triggered and the firmware will not be requested, so there will
not be any unnecessary probe deferring.

I see that the driver you mentioned checks if the system_state is still
not SYSTEM_RUNNING to defer the probe.
I have not tested if something like that would be possible in this case,
but giving up on the first attempt if the firmware is not found makes
the assumption that the filesystem where the fw resides will always be
ready when the probe function is called, which in my particular case is
a wrong assumption.

If the firmware was updated at any point during normal operation, the
assumption would be definitely right, but maybe not while booting.

Thank you and best regards,
Javier Carrasco