linux-kernel - Re: [GIT *] Allow request_firmware() to be satisfied from in-kernel, use it in more drivers.

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:	Tue, 15 Jul 2008 11:57:18 +0200
From:	Marcel Holtmann <marcel@...tmann.org>
To:	David Miller <davem@...emloft.net>
Cc:	akpm@...ux-foundation.org, dwmw2@...radead.org,
	torvalds@...ux-foundation.org, alan@...rguk.ukuu.org.uk,
	linux-kernel@...r.kernel.org, jgarzik@...ox.com, mchan@...adcom.com
Subject: Re: [GIT *] Allow request_firmware() to be satisfied from
	in-kernel, use it in more drivers.

Hi David,

> I'm not happy for network drivers, although I'm happy to see that
> David respected out NACKs on tg3/bnx2/etc. and didn't include those
> bits.
> 
> I still haven't seen an answer to the chip reset issues.  The argument
> has been that this stuff is going to save kernel memory when the
> driver isn't loading firmware, but that's not really possible.
> 
> When a lot of these network drivers reset, due to a transmit timeout
> or other exception, we need to load the firmware again.
> 
> So this means, that if request_firmware() dies or fails for some
> reason in these scenerios, we can't reset the network card.  Something
> as simple as a memory or other allocation failure deep inside of
> request_firmware() means we lose the networking interface.
> 
> To me this seems like a very non-resilient setup.  It makes sense
> to just keep the firmware in-core so we can load it without having
> to even think about possible failures.

actually when we wrote request_firmware() a long time ago, the idea was
to support various kind of setups (although until now only the on-demand
got used).

So one idea was to allow minimal inclusion of firmware as binary blobs
in the driver and allow overwriting them by loading newer version from
the filesystem. This was intended to ensure minimal working drivers. The
main background was that some devices work with a small firmware and
provide basic features and only need extra firmware for advanced
features. Everything suppose to be hidden behind request_firmware() and
a method to register binary blobs as firmware from within a driver. So
the driver developer really doesn't have to invent anything by himself.

We are not there yet and at the moment, I am not sure if this is still a
valid requirement, but David's work goes into the right direction and is
a good start.

Regards

Marcel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/