linux-kernel - Re: [PATCH 2/2] module: Re-enable dynamic debugging for GPL-compatible OOT 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]

Date:	Tue, 01 Nov 2011 12:39:46 +1030
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Ben Hutchings <ben@...adent.org.uk>,
	Jason Baron <jbaron@...hat.com>
Cc:	Nick Bowler <nbowler@...iptictech.com>, Greg KH <greg@...ah.com>,
	Dave Jones <davej@...hat.com>,
	Randy Dunlap <rdunlap@...otime.net>,
	LKML <linux-kernel@...r.kernel.org>,
	Debian kernel maintainers <debian-kernel@...ts.debian.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Subject: Re: [PATCH 2/2] module: Re-enable dynamic debugging for GPL-compatible OOT modules

On Mon, 31 Oct 2011 13:44:17 +0000, Ben Hutchings <ben@...adent.org.uk> wrote:
Non-text part: multipart/signed
> On Mon, 2011-10-31 at 12:29 +1030, Rusty Russell wrote:
> > On Fri, 28 Oct 2011 04:38:14 +0100, Ben Hutchings <ben@...adent.org.uk> wrote:
> > > Dynamic debugging was enabled for GPL-compatible out-of-tree modules
> > > until my addition of TAINT_OOT_MODULE.  It should continue to be
> > > enabled now.
> > 
> > Please just remove the test entirely.
> > 
> > AFAICT there's nothing unique to dynamic debug which means it should
> > avoid taint.  If it oopses, we'll learn all about tainting in the oops
> > message.
> 
> It looks like the dynamic debug facility is not meant to be available to
> proprietary modules.

That was my guess too, but Mathieu (the author) said it was about
malformed modules:

On Wed, 26 Oct 2011 02:15:21 -0400:
> This check for tainted modules was first introduced with markers, and
> then used by tracepoints, and then also by dynamic debug. The rationale
> for this check was mainly to ensure that the marker/tracepoint code
> would not trigger a crash when loading a module with incompatible module
> header, originally compiled for an older kernel, into a newer kernel.
> This problem would happen even if the said module does not contain any
> marker/tracepoint, because we happen to try to use fields that are
> non-existent in the module header.

This is pretty bogus: since they forced the module in the first place,
they can handle the explosion.

So we should drop it altogether.

Thanks,
Rusty.
--
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/