<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/base/firmware_loader/firmware.h, branch linux-6.9.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.9.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.9.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2023-10-27T11:30:38Z</updated>
<entry>
<title>firmware_loader: Abort all upcoming firmware load request once reboot triggered</title>
<updated>2023-10-27T11:30:38Z</updated>
<author>
<name>Mukesh Ojha</name>
<email>quic_mojha@quicinc.com</email>
</author>
<published>2023-10-26T14:27:39Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=effd7c70eaa0440688b60b9d419243695ede3c45'/>
<id>urn:sha1:effd7c70eaa0440688b60b9d419243695ede3c45</id>
<content type='text'>
There could be following scenario where there is a ongoing reboot
is going from processA which tries to call all the reboot notifier
callback and one of them is firmware reboot call which tries to
abort all the ongoing firmware userspace request under fw_lock but
there could be another processB which tries to do request firmware,
which came just after abort done from ProcessA and ask for userspace
to load the firmware and this can stop the ongoing reboot ProcessA
to stall for next 60s(default timeout) which may not be expected
behaviour everyone like to see, instead we should abort any firmware
load request which came once firmware knows about the reboot through
notification.

      ProcessA                             ProcessB

kernel_restart_prepare
  blocking_notifier_call_chain
   fw_shutdown_notify
     kill_pending_fw_fallback_reqs
      __fw_load_abort
       fw_state_aborted                request_firmware
         __fw_state_set                 firmware_fallback_sysfs
...                                       fw_load_from_user_helper
..                                         ...
.                                          ..
                                            usermodehelper_read_trylock
                                             fw_load_sysfs_fallback
                                              fw_sysfs_wait_timeout
usermodehelper_disable
 __usermodehelper_disable
  down_write()

Signed-off-by: Mukesh Ojha &lt;quic_mojha@quicinc.com&gt;
Acked-by: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
Link: https://lore.kernel.org/r/1698330459-31776-2-git-send-email-quic_mojha@quicinc.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>firmware_loader: remove #include &lt;generated/utsrelease.h&gt;</title>
<updated>2022-12-10T01:33:20Z</updated>
<author>
<name>Thomas Weißschuh</name>
<email>linux@weissschuh.net</email>
</author>
<published>2022-11-26T05:09:59Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=bd328def2f987ebd4e20725a490f005556d737bf'/>
<id>urn:sha1:bd328def2f987ebd4e20725a490f005556d737bf</id>
<content type='text'>
utsrelease.h is potentially generated on each build.
By removing this unused include we can get rid of some spurious
recompilations.

Signed-off-by: Thomas Weißschuh &lt;linux@weissschuh.net&gt;
Reviewed-by: Russ Weight &lt;russell.h.weight@intel.com&gt;
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
</content>
</entry>
<entry>
<title>firmware_loader: Add firmware-upload support</title>
<updated>2022-04-26T10:34:28Z</updated>
<author>
<name>Russ Weight</name>
<email>russell.h.weight@intel.com</email>
</author>
<published>2022-04-21T21:22:00Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=97730bbb242cde22b7140acd202ffd88823886c9'/>
<id>urn:sha1:97730bbb242cde22b7140acd202ffd88823886c9</id>
<content type='text'>
Extend the firmware subsystem to support a persistent sysfs interface that
userspace may use to initiate a firmware update. For example, FPGA based
PCIe cards load firmware and FPGA images from local FLASH when the card
boots. The images in FLASH may be updated with new images provided by the
user at his/her convenience.

A device driver may call firmware_upload_register() to expose persistent
"loading" and "data" sysfs files. These files are used in the same way as
the fallback sysfs "loading" and "data" files. When 0 is written to
"loading" to complete the write of firmware data, the data is transferred
to the lower-level driver using pre-registered call-back functions. The
data transfer is done in the context of a kernel worker thread.

Reviewed-by: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
Reviewed-by: Tianfei zhang &lt;tianfei.zhang@intel.com&gt;
Tested-by: Matthew Gerlach &lt;matthew.gerlach@linux.intel.com&gt;
Signed-off-by: Russ Weight &lt;russell.h.weight@intel.com&gt;
Link: https://lore.kernel.org/r/20220421212204.36052-5-russell.h.weight@intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>firmware_loader: Check fw_state_is_done in loading_store</title>
<updated>2022-04-22T15:13:54Z</updated>
<author>
<name>Russ Weight</name>
<email>russell.h.weight@intel.com</email>
</author>
<published>2022-04-21T21:21:58Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=736da0b657f615db7e29606eb8818871534a8943'/>
<id>urn:sha1:736da0b657f615db7e29606eb8818871534a8943</id>
<content type='text'>
Rename fw_sysfs_done() and fw_sysfs_loading() to fw_state_is_done() and
fw_state_is_loading() respectively, and place them along side companion
functions in drivers/base/firmware_loader/firmware.h.

Use the fw_state_is_done() function to exit early from
firmware_loading_store() if the state is already "done". This is being done
in preparation for supporting persistent sysfs nodes to allow userspace to
upload firmware to a device, potentially reusing the sysfs loading and data
files multiple times.

Reviewed-by: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
Reviewed-by: Tianfei zhang &lt;tianfei.zhang@intel.com&gt;
Tested-by: Matthew Gerlach &lt;matthew.gerlach@linux.intel.com&gt;
Signed-off-by: Russ Weight &lt;russell.h.weight@intel.com&gt;
Link: https://lore.kernel.org/r/20220421212204.36052-3-russell.h.weight@intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>firmware_loader: formalize built-in firmware API</title>
<updated>2021-10-22T12:13:44Z</updated>
<author>
<name>Luis Chamberlain</name>
<email>mcgrof@kernel.org</email>
</author>
<published>2021-10-21T15:58:34Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=48d09e97876bed4bcc503d528bdba8c907e43cb3'/>
<id>urn:sha1:48d09e97876bed4bcc503d528bdba8c907e43cb3</id>
<content type='text'>
Formalize the built-in firmware with a proper API. This can later
be used by other callers where all they need is built-in firmware.

We export the firmware_request_builtin() call for now only
under the TEST_FIRMWARE symbol namespace as there are no
direct modular users for it. If they pop up they are free
to export it generally. Built-in code always gets access to
the callers and we'll demonstrate a hidden user which has been
lurking in the kernel for a while and the reason why using a
proper API was better long term.

Reviewed-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
Link: https://lore.kernel.org/r/20211021155843.1969401-2-mcgrof@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>firmware_loader: fix use-after-free in firmware_fallback_sysfs</title>
<updated>2021-07-29T15:22:15Z</updated>
<author>
<name>Anirudh Rayabharam</name>
<email>mail@anirudhrb.com</email>
</author>
<published>2021-07-28T08:51:07Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=75d95e2e39b27f733f21e6668af1c9893a97de5e'/>
<id>urn:sha1:75d95e2e39b27f733f21e6668af1c9893a97de5e</id>
<content type='text'>
This use-after-free happens when a fw_priv object has been freed but
hasn't been removed from the pending list (pending_fw_head). The next
time fw_load_sysfs_fallback tries to insert into the list, it ends up
accessing the pending_list member of the previously freed fw_priv.

The root cause here is that all code paths that abort the fw load
don't delete it from the pending list. For example:

        _request_firmware()
          -&gt; fw_abort_batch_reqs()
              -&gt; fw_state_aborted()

To fix this, delete the fw_priv from the list in __fw_set_state() if
the new state is DONE or ABORTED. This way, all aborts will remove
the fw_priv from the list. Accordingly, remove calls to list_del_init
that were being made before calling fw_state_(aborted|done).

Also, in fw_load_sysfs_fallback, don't add the fw_priv to the pending
list if it is already aborted. Instead, just jump out and return early.

Fixes: bcfbd3523f3c ("firmware: fix a double abort case with fw_load_sysfs_fallback")
Cc: stable &lt;stable@vger.kernel.org&gt;
Reported-by: syzbot+de271708674e2093097b@syzkaller.appspotmail.com
Tested-by: syzbot+de271708674e2093097b@syzkaller.appspotmail.com
Reviewed-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Acked-by: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
Signed-off-by: Anirudh Rayabharam &lt;mail@anirudhrb.com&gt;
Link: https://lore.kernel.org/r/20210728085107.4141-3-mail@anirudhrb.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>firmware: Add request_partial_firmware_into_buf()</title>
<updated>2020-10-05T11:37:04Z</updated>
<author>
<name>Scott Branden</name>
<email>scott.branden@broadcom.com</email>
</author>
<published>2020-10-02T17:38:27Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=59cdb23ca2dfef3b93411d1105409dfe9cd1f62f'/>
<id>urn:sha1:59cdb23ca2dfef3b93411d1105409dfe9cd1f62f</id>
<content type='text'>
Add request_partial_firmware_into_buf() to allow for portions of a
firmware file to be read into a buffer. This is needed when large firmware
must be loaded in portions from a file on memory constrained systems.

Signed-off-by: Scott Branden &lt;scott.branden@broadcom.com&gt;
Co-developed-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Link: https://lore.kernel.org/r/20201002173828.2099543-16-keescook@chromium.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>firmware: Store opt_flags in fw_priv</title>
<updated>2020-10-05T11:37:04Z</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2020-10-02T17:38:26Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=89287c169f8ff79d466b274da1d5c862e8b29152'/>
<id>urn:sha1:89287c169f8ff79d466b274da1d5c862e8b29152</id>
<content type='text'>
Instead of passing opt_flags around so much, store it in the private
structure so it can be examined by internals without needing to add more
arguments to functions.

Co-developed-by: Scott Branden &lt;scott.branden@broadcom.com&gt;
Signed-off-by: Scott Branden &lt;scott.branden@broadcom.com&gt;
Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Link: https://lore.kernel.org/r/20201002173828.2099543-15-keescook@chromium.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>firmware_loader: fix memory leak for paged buffer</title>
<updated>2020-08-28T09:32:07Z</updated>
<author>
<name>Prateek Sood</name>
<email>prsood@codeaurora.org</email>
</author>
<published>2020-08-20T20:57:50Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=4965b8cd1bc1ffb017e5c58e622da82b55e49414'/>
<id>urn:sha1:4965b8cd1bc1ffb017e5c58e622da82b55e49414</id>
<content type='text'>
vfree() is being called on paged buffer allocated
using alloc_page() and mapped using vmap().

Freeing of pages in vfree() relies on nr_pages of
struct vm_struct. vmap() does not update nr_pages.
It can lead to memory leaks.

Fixes: ddaf29fd9bb6 ("firmware: Free temporary page table after vmapping")
Signed-off-by: Prateek Sood &lt;prsood@codeaurora.org&gt;
Reviewed-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/1597957070-27185-1-git-send-email-prsood@codeaurora.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>firmware_loader: change enum fw_opt to u32</title>
<updated>2020-05-27T10:20:47Z</updated>
<author>
<name>Scott Branden</name>
<email>scott.branden@broadcom.com</email>
</author>
<published>2020-05-22T23:12:02Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c2c076166b5880eabe068ce1cab30bf6edeeea1a'/>
<id>urn:sha1:c2c076166b5880eabe068ce1cab30bf6edeeea1a</id>
<content type='text'>
"enum fw_opt" is not used as an enum.
Change fw_opt to u32 as FW_OPT_* values are OR'd together.

Signed-off-by: Scott Branden &lt;scott.branden@broadcom.com&gt;
Acked-by: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
Link: https://lore.kernel.org/r/20200522231202.13681-1-scott.branden@broadcom.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
