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, 07 Jul 2008 15:05:49 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	alan@...rguk.ukuu.org.uk
Cc:	mchan@...adcom.com, dwmw2@...radead.org, bastian@...di.eu.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] bnx2 - use request_firmware()

From: Alan Cox <alan@...rguk.ukuu.org.uk>
Date: Mon, 7 Jul 2008 22:19:50 +0100

> 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)

The firmware needs to be reloaded every time the chip resets.
You're not saving anything.

Or do you want a request_firmware() call failure to hose your
ethernet device when it gets a TX timeout?

<sarcasm>
Sounds like a real error resiliant system to me...
</sarcasm>

Distribution vendors can just as easily ship the driver itself
seperately to get the firmware update.  And by getting it together the
user knows they are receiving something the driver maintainer tested
as a unit.

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

Distribution vendors just want the separation so that they don't have
to keep patching the fimrware out of the tg3.c driver source every
single release, as some do :-)

> 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.

See above, you aren't saving anything.  The firmware needs to stay
around so it can be reloaded into the card during exceptions.

That is, unless you want a more failure prone system.

> Driver authors aren't God.

They (actually, more specifically the maintainers) to a certain extent
are, because they are the ones who eat doo-doo when something explodes.

 There are other important considerations, but
> for tg3 if that means 'wrong MD5sum, no load' then fine.

So in your "firmware updated seperately" argument above how in the
world does this work?  How can you update the firmware seperately if
the MD5sum check is in the driver itself?
--
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/