linux-kernel - Re: [PATCH] Linux Kernel Markers Support for Proprierary Modules

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: <Pine.LNX.4.64.0801250840340.12676@fbirervta.pbzchgretzou.qr>
Date:	Fri, 25 Jan 2008 08:56:09 +0100 (CET)
From:	Jan Engelhardt <jengelh@...putergmbh.de>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
cc:	Andrew Morton <akpm@...ux-foundation.org>, Valdis.Kletnieks@...edu,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Christoph Hellwig <hch@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jon Masters <jcm@...hat.com>
Subject: Re: [PATCH] Linux Kernel Markers Support for Proprierary Modules


On Jan 24 2008 07:47, Mathieu Desnoyers wrote:
>On Tue, 2008-01-22 at 22:10 -0500, Mathieu Desnoyers wrote:
>On my part, its mostly a matter of not crashing the kernel when someone
>tries to force modprobe of a proprietary module (where the checksums
>doesn't match) on a kernel that supports the markers. Not doing so
>causes the markers to try to find the marker-specific information in
>struct module which doesn't exist and OOPSes.

>* Frank Ch. Eigler (fche@...hat.com) wrote:
>[...]
>Another way of looking at this though is that by allowing/encouraging
>proprietary module writers to include markers, we and their users get
>new diagnostic capabilities.  It constitutes a little bit of opening
>up, which IMO we should reward rather than punish.


Tackling this from a different angle:

I do not think there is a real reason to forceload a module, even
those with proprietary origin (vmware) or that are of
partially-closed nature (nvidia). vmware source is fully available,
so can be compiled with proper modinfo/vermagic/markers; nvidia uses
a build system trick to include an .o blob, but eventually its .ko
also ends up with a correct modinfo/vermagic.

Forceload is for people which like to trade an unstable system for
not having to install gcc and kernel-source.


>Remember - when a user tries a Linux box with a proprietary module, and the
>experience sucks because the module sucks, they will walk away thinking
>"Linux sucks", not "That module sucks".

So what is needed is an Oops with an explaining message
if (kernel_tainted) "blame that proprietary module first",
and make sure the user sees that oops even if in X.
--
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/