[lkml]   [2014]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH] Fix: module signature vs tracepoints: add new TAINT_UNSIGNED_MODULE
----- Original Message -----
> From: "Steven Rostedt" <>
> To: "Ingo Molnar" <>
> Cc: "Mathieu Desnoyers" <>,, "Ingo Molnar"
> <>, "Thomas Gleixner" <>, "Rusty Russell" <>, "David Howells"
> <>, "Greg Kroah-Hartman" <>
> 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 <> wrote:
> >
> > * Mathieu Desnoyers <> 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 <>
> 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:


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.



Mathieu Desnoyers
EfficiOS Inc.

 \ /
  Last update: 2014-02-12 07:21    [W:0.089 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site