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]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ