[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140220230938.0bf9614b@gandalf.local.home>
Date: Thu, 20 Feb 2014 23:09:38 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Rusty Russell <rusty@...tcorp.com.au>
Cc: Ingo Molnar <mingo@...nel.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
David Howells <dhowells@...hat.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Johannes Berg <johannes@...solutions.net>
Subject: Re: [RFC PATCH] Fix: module signature vs tracepoints: add new
TAINT_UNSIGNED_MODULE
On Fri, 21 Feb 2014 09:39:18 +1030
Rusty Russell <rusty@...tcorp.com.au> wrote:
> >> comment "Do not forget to sign required modules with scripts/sign-file"
> >> depends on MODULE_SIG_FORCE && !MODULE_SIG_ALL
> >>
> >> Then you didn't do that. You broke it, you get to keep both pieces.
> >
> > In this case we should fail the module load all together, and require
> > insmod to add the --force flag to load it. Why the hell are we setting
> > a FORCED_MODULE flag when no module was forced????
>
> If this mistake of creating unsigned modules is common, then it would be
> friendly to do something about it, yes.
I just got another report about it happening again today.
>
> Perhaps we should append UNSIGNED to vermagic, and then strip that out
> when we sign the module? That would have this effect.
If it makes the user have to use --force, then they will be more aware
something went wrong when things are not working.
I still find it strange that things like tracepoints are not working on
a module just because it wasn't signed. I can see someone adding
something and not doing the signing, and wonder why tracepoints are
broken. Right now, I'm the one that gets the bug reports, not you :-(
Them: "Tracepoints are broken".
Me: "What do you mean tracepoints are broken?"
Them: "I enabled them, but don't see them being recorded"
Me: "Is this for tracepoints in a module?"
Them: "Yes"
Me: "Oh, this again. Do you have MODULE_SIG_FORCE & !MODULE_SIG_ALL
set, and you didn't sign your module?"
Them: "Yes"
Me: "Well that's your problem."
Them: "What does that have to do with tracepoints?"
Me: "Well, loading a non signed module into a kernel that requires
sigs, sets the FORCED_MODULE flag, and that breaks tracepoints"
Them: "Why? The module is from the same kernel and built with the same
tool chain"
Me: "it just does"
Them: "I'm just working on this module, and I want to trace it, but
don't want to keep signing it"
Me: "Oh well, that's just the way it goes"
Them: "Why?"
When honestly, just adding another taint flag and let tracepoints
still load would keep people from pestering me about it.
The only reason we don't trace FORCED_MODULE modules, is because it may
have an older data structure, or different tracepoint logic. We avoid
adding tracepoints on those because we don't want bug reports from
people using tracepoints in modules that were compiled for a different
kernel, because that could cause havoc. Ironically, having tracepoints
not added for modules with that taint is causing more bug reports due
to this signing issue. Maybe I'll just let tracepoints work with modules
that have that taint and deal with the bug reports that are caused by
people loading older modules into newer kernels.
-- Steve
--
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