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
next prev parent 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