Re: [PATCH] module,bug: Add TAINT_OOT_MODULE flag for modules not built in-tree

[Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>]

* Rusty Russell (rusty@rustcorp.com.au) wrote:
> On Tue, 25 Oct 2011 16:17:24 -0400, Dave Jones <davej@redhat.com> wrote:
> > commit 7816c45bf13255157c00fb8aca86cb64d825e878
> > Author: Roland Vossen <rvossen@broadcom.com>
> > Date:   Thu Apr 7 11:20:58 2011 +0200
> > 
> >     modules: Enabled dynamic debugging for staging modules
> ...
> >     
> >     Signed-off-by: Roland Vossen <rvossen@broadcom.com>
> >     Acked-by: Jason Baron <jbaron@redhat.com>
> >     Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 
> Greg, you know better.  This is why we have maintainers: I can't track
> patches I don't see.  Grrr...
> 
> > If we want to support out of tree modules with this, should we just nuke the
> > whole check, or do we still want to prevent certain types of tainted kernels
> > from using this stuff ?
> 
> It goes back to the first implementation of kernel markers.  IIRC, it
> was to prevent dynamic debug stuff from circumventing licensing, but
> testing for *any* taint seems overbroad.  Mathieu?

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.

AFAIK, dynamic debug use a similar trick that require extra members in
the module header, so checking that the module header format is
compatible with the kernel would be enough. Is there a taint flag that
allows us to check for this more narrowly ? TAINT_FORCED_MODULE would
probably be the closest one we have now, although we might want to be
more specific than that.

Thanks,

Mathieu

> 
> Thanks,
> Rusty.
> PS.  Can't see how this related to lockdep either...

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com