linux-kernel - Re: livepatch: Implement separate coming and going module notifiers

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]

Date:	Fri, 29 Jan 2016 14:20:23 -0600
From:	Josh Poimboeuf <jpoimboe@...hat.com>
To:	Jessica Yu <jeyu@...hat.com>
Cc:	Miroslav Benes <mbenes@...e.cz>,
	Seth Jennings <sjenning@...hat.com>,
	Jiri Kosina <jikos@...nel.org>,
	Vojtech Pavlik <vojtech@...e.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...hat.com>, live-patching@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: livepatch: Implement separate coming and going module notifiers

On Fri, Jan 29, 2016 at 03:04:51PM -0500, Jessica Yu wrote:
> +++ Josh Poimboeuf [29/01/16 11:30 -0600]:
> >On Fri, Jan 29, 2016 at 05:30:46PM +0100, Miroslav Benes wrote:
> >>Otherwise than that it looks good. I agree there are advantages to split
> >>the notifiers. For example we can replace the coming one with the function
> >>call somewhere in load_module() to improve error handling if the patching
> >>fails while loading a module. This would be handy with a consistency model
> >>in the future.
> >
> >Yeah, we'll need something like that eventually.  Though we'll need to
> >make sure that ftrace_module_enable() is still called beforehand, after
> >setting MODULE_STATE_COMING state, due to the race described in 5156dca.
> >
> >Something like:
> >
> >[note: klp_module_notify_coming() is replaced with klp_module_enable()]
> >
> >diff --git a/kernel/module.c b/kernel/module.c
> >index 8358f46..aeabd81 100644
> >--- a/kernel/module.c
> >+++ b/kernel/module.c
> >@@ -3371,6 +3371,13 @@ static int complete_formation(struct module *mod, struct load_info *info)
> >	mod->state = MODULE_STATE_COMING;
> >	mutex_unlock(&module_mutex);
> >
> >+	ftrace_module_enable(mod);
> >+	err = klp_module_enable(mod);
> >+	if (err) {
> >+		ftrace_release_mod(mod);
> >+		return err;
> >+	}
> 
> If we go this route, should we should print a big warning ("Livepatch
> couldn't patch loading module X") instead of aborting the module load
> completely?

I think aborting the module load is better.  Otherwise the patch would
be applied in an inconsistent state.  Which might not be all that bad
now, since we don't have a consistency model anyway; but it could be
disastrous once we get one, if somebody is relying on that consistency.

-- 
Josh