archive mirror
 help / color / mirror / Atom feed
From: Luis Chamberlain <>
To: Scott Branden <>
Cc: Greg Kroah-Hartman <>,
	Andy Gross <>,
	David Brown <>,
	Alexander Viro <>,
	Shuah Khan <>,,
	"Rafael J . Wysocki" <>,,,,
	BCM Kernel Feedback <>,
	Olof Johansson <>,
	Andrew Morton <>,
	Dan Carpenter <>,
	Colin Ian King <>,
	Kees Cook <>, Takashi Iwai <>,
Subject: Re: [PATCH 3/3] firmware: add mutex fw_lock_fallback for race condition
Date: Tue, 20 Aug 2019 01:26:55 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Aug 19, 2019 at 09:19:51AM -0700, Scott Branden wrote:
> To be honest, I find the entire firmware code sloppy.

And that is after years of cleanup on my part. Try going back to v4.1
for instance, check the code out then for an incredible horrific sight :)

> I don't think the cache/no-cache feature is
> implemented or tested properly nor fallback to begin with.

I'm in total agreement! I *know* there must be holes in that code, and I
acknowledge a few possible gotchas on the commit logs. For instance, I
acknowledged that the firmware cache had a secondary purpose which was
not well documented or understood through commit e44565f62a720
("firmware: fix batched requests - wake all waiters"). The firmware
cache allows for batching requests and sharing the same original request
for multiple consecutive requests which *race against each other*.
That's when I started having my doubts about the architecture of the
firmware cache mechanism, it seemed too complex and perhaps overkill
and considered killing it.

As I noted in that commit, the firmware cache is used for:
1) Addressing races with file lookups during the suspend/resume cycle by
keeping firmware in memory during the suspend/resume cycle
2) Batched requests for the same file rely only on work from the first
file lookup, which keeps the firmware in memory until the last
release_firmware() is called

Also worth quoting from that commit as well:

"Batched requests *only* take effect if secondary requests come in
prior to the first user calling release_firmware(). The devres name used
for the internal firmware cache is used as a hint other pending requests
are ongoing, the firmware buffer data is kept in memory until the last
user of the buffer calls release_firmware(), therefore serializing
requests and delaying the release until all requests are done."

Later we discovered that the firmware cache had a serious security issue
since its inception through commit 422b3db2a503 ("firmware: Fix security
issue with request_firmware_into_buf()"). Granted, exploiting this would
require the ability to load kernel code, so the vector of exploitation
is rather small.

The cache stuff cannot be removed as it *at least* resolves the fw
suspend stuff, but still, this can likely use a revisit in rachitecture
long term. The second implicit use case for batched requests however
seems complex and not sure if its worth to maintain. I'll note that
at least some drivers *do* their own firmware caching, iwlwifi, is one,
so there is an example there to allow drivers to say "I actually don't
need caching" for the future.

If you're volunteering to cleaning / testing the cache stuff I highly
welcome that. That and the fallback stuff has been needing testing for
years. Someoone was working on patches on the test case for cache stuff
a while ago, from Intel, but they disappeared.

> I'm not claiming this patch is the final
> solution and indicated such in the cover letter and the comment above.

I missed that sorry.

> I hope there is someone more familiar with this code to comment further and
> come up with a proper solution.

Alright, I'll dig in and take a look, and propose an alternative.

> I have found numerous issues and race conditions with the firmware code (I
> simply added a test).

That is nothing compared to the amount of fixes I have found and
actually fixed too, the code was a nightmare before I took on

> 1) Try loading the same valid firmware using no-cache once it has already
> been loaded with cache.


> It won't work, which is why I had to use a different filename in the test
> for request_firmware_into_buf.

Alright, I'll go try to fix this. Thanks for the report.

> 2) Try removing the "if (opt_flags & FW_OPT_NOCACHE)" in my patch and always
> call the mutex.
> The firmware test will lock up during a "no uevent" test.  I am not familiar
> with the code to
> know why such is true and what issue this exposes in the code.

I hinted in my review of the oops what the issue was.

> 3) I have a driver that uses request_firmware_into_buf and have multiple
> instances of the driver

Cool, is the driver upstream?

> loading the same firmware in parallel.  Some of the data is not read
> correctly in each instance.

Makes perfect sense considering the lack of testing I noted.

> I haven't yet to reproduce this issue with the firmware test 

That's because of batched firmware request mechanism.

> but currently
> have a mutex around the entire
> call to request_firmware_into_buf in our driver.

I will take a look at this now.

> Perhaps it is better at this point to add a mutex in
> request_firmware_into_buf to make is entirely safe?

No, that is not sufficient, although it would also solve the

> (Perhaps even with every request_firmware functions as none seems to be
> tested properly.)

No, you are incorrect. The other firmware API calls *have* been
elaborately tested. The firmware cache stuff *is a mess* however,
since we *use and support it*, I've done my best to salvage it and
document it.

I'll take a look at this and propose an alternative solution.


  reply	other threads:[~2019-08-20  1:27 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-16  0:09 [PATCH 0/3] firmware: selftest for request_firmware_into_buf Scott Branden
2019-08-16  0:09 ` [PATCH 1/3] test_firmware: add support " Scott Branden
2019-08-19  5:24   ` Luis Chamberlain
2019-08-19 20:27     ` shuah
2019-08-16  0:09 ` [PATCH 2/3] selftest: firmware: Add request_firmware_into_buf tests Scott Branden
2019-08-19  5:24   ` Luis Chamberlain
2019-08-19 20:27     ` shuah
2019-08-16  0:09 ` [PATCH 3/3] firmware: add mutex fw_lock_fallback for race condition Scott Branden
2019-08-19  5:39   ` Luis Chamberlain
2019-08-19 16:19     ` Scott Branden
2019-08-20  1:26       ` Luis Chamberlain [this message]
2019-08-20 15:54         ` Scott Branden
2019-08-23 10:31         ` Takashi Iwai
2019-08-23 15:43           ` Luis Chamberlain
2019-08-23 19:56             ` Scott Branden
2019-08-23 19:48           ` Scott Branden

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH 3/3] firmware: add mutex fw_lock_fallback for race condition' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).