linux-kernel - Re: [PATCH] bnx2 - use request

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:	Mon, 7 Jul 2008 22:19:50 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	David Miller <davem@...emloft.net>
Cc:	mchan@...adcom.com, dwmw2@...radead.org, bastian@...di.eu.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] bnx2 - use request_firmware()

> Who in the world is going to actually want request_firmware() to find
> a firmware image other than the one which has been properly tested
> together with the driver by the driver maintainer?

That misses the point, intentionally I am sure. In the majority of cases
the firmware doesn't change between releases so shipping a billion copies
of is a pain in the butt.

> What "use case" is there other than the desire to seperate out the
> firmware in order to skirt the legal issues?

Not shipping lots of copies
Not leaving crap locked in kernel memory when it isn't needed
Letting vendors issue firmware updates (which especially in enterprise
space is a big issue and right now gets messy with compiled in firmware)

> I think it is, in fact, the driver maintainer's perogative of whether
> they want request_firmware() to be supported by their driver or not.
> It is they who have to deal with any possible fallout.

And their users and the distributors for whom it can cause enormous pain.

If the two are closely tied then it makes a lot of sense to keep them
tied, but that doesn't mean wasting a ton of kernel memory and bandwidth
and disk space in the process. Loading the firmware and insisting on a
specific version is quite civilised for a driver with such a tie.

(of course we had this argument over ten years ago about modules when
various authors couldn't be bothered to modularise their driver which
caused endless pain to the distributions and end users. Remember the
sound driver situation in early Red Hat. Mind you it got me a job there
fixing it ;))

Driver authors aren't God. There are other important considerations, but
for tg3 if that means 'wrong MD5sum, no load' then fine.

Alan
--
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/