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:	Wed, 26 Oct 2011 02:15:21 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	Dave Jones <davej@...hat.com>, Greg KH <greg@...ah.com>,
	Nick Bowler <nbowler@...iptictech.com>,
	Ben Hutchings <ben@...adent.org.uk>,
	Randy Dunlap <rdunlap@...otime.net>,
	LKML <linux-kernel@...r.kernel.org>,
	Debian kernel maintainers <debian-kernel@...ts.debian.org>,
	Roland Vossen <rvossen@...adcom.com>
Subject: Re: [PATCH] module,bug: Add TAINT_OOT_MODULE flag for modules not
	built in-tree

* Rusty Russell (rusty@...tcorp.com.au) wrote:
> On Tue, 25 Oct 2011 16:17:24 -0400, Dave Jones <davej@...hat.com> wrote:
> > commit 7816c45bf13255157c00fb8aca86cb64d825e878
> > Author: Roland Vossen <rvossen@...adcom.com>
> > Date:   Thu Apr 7 11:20:58 2011 +0200
> > 
> >     modules: Enabled dynamic debugging for staging modules
> ...
> >     
> >     Signed-off-by: Roland Vossen <rvossen@...adcom.com>
> >     Acked-by: Jason Baron <jbaron@...hat.com>
> >     Signed-off-by: Greg Kroah-Hartman <gregkh@...e.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
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ