linux-kernel - Re: [PATCH v6 3/8] firmware_loader: Move module refcounts to allow unloading

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: <67363ecf8a693_214c294dd@dwillia2-xfh.jf.intel.com.notmuch>
Date: Thu, 14 Nov 2024 10:17:51 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: Russ Weight <russ.weight@...ux.dev>, Dan Williams
	<dan.j.williams@...el.com>
CC: Dionna Glaze <dionnaglaze@...gle.com>, <linux-kernel@...r.kernel.org>,
	<x86@...nel.org>, Luis Chamberlain <mcgrof@...nel.org>, Danilo Krummrich
	<dakr@...hat.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "Rafael
 J. Wysocki" <rafael@...nel.org>, Tianfei zhang <tianfei.zhang@...el.com>,
	<linux-coco@...ts.linux.dev>, Sean Christopherson <seanjc@...gle.com>, "Paolo
 Bonzini" <pbonzini@...hat.com>, Thomas Gleixner <tglx@...utronix.de>, "Ingo
 Molnar" <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Dave Hansen
	<dave.hansen@...ux.intel.com>, Ashish Kalra <ashish.kalra@....com>, "Tom
 Lendacky" <thomas.lendacky@....com>, John Allen <john.allen@....com>,
	"Herbert Xu" <herbert@...dor.apana.org.au>, "David S. Miller"
	<davem@...emloft.net>, Michael Roth <michael.roth@....com>, Alexey
 Kardashevskiy <aik@....com>, "Russ Weight" <russell.h.weight@...el.com>
Subject: Re: [PATCH v6 3/8] firmware_loader: Move module refcounts to allow
 unloading

Russ Weight wrote:
[..]
> Clearly this would be an unexpected/unusual case. Someone with root
> access would have to remove the device driver. I'm not sure how much
> effort should be expended in preventing it - but this is the reasoning
> behind the incrementing/decrementing of the module reference counts.

The module reference needs to be held only if the producer of those
symbols can be removed without triggering some coordinated removal with
action consumer. A driver that fails to call
firmware_upload_unregister() in its module removal path is simply a driver
with a memory-leak and use-after-free bug, not something the firmware
upload core needs to worry about.

So, the prevention mechanism is "thou shalt use
firmware_upload_unregister() correctly", and when that is in place
explicit module references are not only redundant, but trying to
implement them causes circular dependency loops.