public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Ingo Molnar <mingo@kernel.org>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Rusty Russell <rusty@rustcorp.com.au>,
	David Howells <dhowells@redhat.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [RFC PATCH] Fix: module signature vs tracepoints: add new TAINT_UNSIGNED_MODULE
Date: Wed, 12 Feb 2014 05:51:33 +0000 (UTC)	[thread overview]
Message-ID: <269616647.23590.1392184293963.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <20140211234534.6bc34e57@gandalf.local.home>

----- Original Message -----
> From: "Steven Rostedt" <rostedt@goodmis.org>
> To: "Ingo Molnar" <mingo@kernel.org>
> Cc: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>, linux-kernel@vger.kernel.org, "Ingo Molnar"
> <mingo@redhat.com>, "Thomas Gleixner" <tglx@linutronix.de>, "Rusty Russell" <rusty@rustcorp.com.au>, "David Howells"
> <dhowells@redhat.com>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>
> Sent: Tuesday, February 11, 2014 11:45:34 PM
> Subject: Re: [RFC PATCH] Fix: module signature vs tracepoints: add new TAINT_UNSIGNED_MODULE
> 
> On Tue, 11 Feb 2014 08:27:38 +0100
> Ingo Molnar <mingo@kernel.org> wrote:
> 
> > 
> > * Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> > 
> > > Users have reported being unable to trace non-signed modules loaded
> > > within a kernel supporting module signature.
> > 
> > External modules should strive to get out of the 'crap' and
> > 'felony law breaker' categories and we should not make it
> > easier for them to linger in a broken state.
> > 
> > Nacked-by: Ingo Molnar <mingo@kernel.org>
> 
> I'm not sure how great this idea is, but it isn't the same as the
> "crap" and "fenony law breaker" categories. Having a non-signed module
> doesn't mean that it isn't fully GPL compliant, it just means that it
> hasn't been signed. There's several things that can taint the kernel
> when loading a module. Being non GPL compliant is just one of them, and
> that will never be allowed to accept tracepoints.
> 
> Forcing a module that was built for a different kernel version gives us
> another taint, which we don't add tracepoints for, not because it is
> not compliant, but because that could corrupt the kernel as we can
> not guarantee the binary structure layout of those modules would be the
> same as what the kernel was built with. We don't want people
> complaining about tracepoint failures due to forcing an older module
> into a newer kernel with different tracepoint structures.
> 
> But if the kernel expects to have signed modules, and you force a
> module to be loaded that is not signed, then you still get that
> "forced" module taint, which is the same one as loading a module from
> an older kernel into a newer kernel. It's a different problem, and I
> can see having a different taint flag be more informative to kernel
> developers in general. I would welcome that change with or without
> letting tracepoints be set for that module.
> 
> But I have to ask Mathieu, what exactly is the use case here? If you
> have a kernel that expects to only load signed modules, why would you
> want to force non signed ones? That basically breaks the whole purpose
> of signing modules. Once you allow a non signed module to be loaded
> then the kernel can be considered compromised. That is, you just gave
> kernel access to an untrusted source.

The use-case is with a kernel that has this config:

CONFIG_MODULE_SIG=y
# CONFIG_MODULE_SIG_FORCE is not set

which is the case for at least Ubuntu kernels (that I know of). It allows
users to specify the kernel boot argument "module.sig_enforce" if they care
about refusing unsigned modules.

The use-case targeted here is loading GPL compliant out-of-tree modules
with those kernels, obviously not using the kernel boot argument
"module.sig_enforce". Tracepoints contained within those modules are
silently skipped due to the TAINT_FORCED_MODULE flag.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

  reply	other threads:[~2014-02-12  5:51 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-10 23:23 [RFC PATCH] Fix: module signature vs tracepoints: add new TAINT_UNSIGNED_MODULE Mathieu Desnoyers
2014-02-11  7:27 ` Ingo Molnar
2014-02-12  4:45   ` Steven Rostedt
2014-02-12  5:51     ` Mathieu Desnoyers [this message]
2014-02-13  3:24     ` Rusty Russell
2014-02-13 21:11       ` Steven Rostedt
2014-02-13 21:24         ` Steven Rostedt
2014-02-14  3:32           ` Mathieu Desnoyers
2014-02-14  0:51         ` Rusty Russell
2014-02-16 23:58           ` Mathieu Desnoyers
2014-02-20 15:30           ` Steven Rostedt
2014-02-20 23:09             ` Rusty Russell
2014-02-21  4:09               ` Steven Rostedt
2014-02-21  8:10                 ` Johannes Berg
2014-02-26  2:51                   ` Rusty Russell
2014-02-26 12:55                     ` Mathieu Desnoyers
2014-02-13 15:10     ` Mathieu Desnoyers
2014-02-13 15:28       ` Steven Rostedt
2014-02-13 15:36         ` Frank Ch. Eigler
2014-02-13 15:44           ` Steven Rostedt
2014-02-13 21:42             ` Arend van Spriel
2014-02-13 15:41         ` Mathieu Desnoyers
2014-02-13 20:45           ` Steven Rostedt
2014-02-14  3:49             ` Mathieu Desnoyers
2014-02-24 15:54               ` Steven Rostedt
2014-02-24 16:55                 ` Mathieu Desnoyers
2014-02-24 17:39                   ` Steven Rostedt
2014-02-24 17:58                     ` Mathieu Desnoyers
2014-02-24 18:25                       ` Steven Rostedt
2014-02-26 19:55                       ` Steven Rostedt
2014-02-26  2:53                     ` Rusty Russell
2014-02-26 20:13                       ` Steven Rostedt
2014-02-24 18:32                 ` Mathieu Desnoyers
2014-02-24 19:10                   ` Steven Rostedt
2014-02-26 14:23                     ` Mathieu Desnoyers
2014-02-26 15:05                       ` Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=269616647.23590.1392184293963.JavaMail.zimbra@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=dhowells@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=rusty@rustcorp.com.au \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox