linux-kernel - RE: [PATCH v5 04/10] platform/x86/intel/ifs: Read IFS firmware image

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:   Wed, 4 May 2022 16:49:07 +0000
From:   "Luck, Tony" <tony.luck@...el.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        "hdegoede@...hat.com" <hdegoede@...hat.com>,
        "markgross@...nel.org" <markgross@...nel.org>
CC:     "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
        "corbet@....net" <corbet@....net>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "andriy.shevchenko@...ux.intel.com" 
        <andriy.shevchenko@...ux.intel.com>,
        "Joseph, Jithu" <jithu.joseph@...el.com>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "platform-driver-x86@...r.kernel.org" 
        <platform-driver-x86@...r.kernel.org>,
        "patches@...ts.linux.dev" <patches@...ts.linux.dev>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>
Subject: RE: [PATCH v5 04/10] platform/x86/intel/ifs: Read IFS firmware image

>> +	ret = request_firmware_direct(&fw, scan_path, dev);
>> +	if (ret) {
>> +		dev_err(dev, "ifs file %s load failed\n", scan_path);
>> +		return;
>
> Why is this not returning an error to the caller?

There are three call sequences that lead here:

1) CONFIG_INTEL_IFS=y
    At boot this is pretty much guaranteed to fail (unless some crazy person includes the
   scan file in the initramfs). In this case there isn't a useful caller to return the code to.
   In this case the driver init routine must ignore any error to make sure the sysfs reload
   file is present to load the scan file once the file system is available.

2) CONFIG_INTEL_IFS=m module load time
    Same code path as built-in ... so must ignore a failed load here too (unless there is a
    way to distinguish the built-in vs. module execution environment).

3) echo 1 > reload
    Hmmm. Some older revision did return an error ... but I seem to have factored it out
   during cleanups. Limited to standard -E???? error codes. The reload_store() function
   can just check whether the load succeeded by looking at ifsd->loaded instead of a
   return value from ifs_load_firmware()

So, I will fix case 3. But probably by checking ifsd->loaded rather than by adding a return
code to this function.

-Tony