linux-kernel - Re: [PATCH 1/2] 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]

Message-ID: <alpine.LNX.2.00.1601292017380.19898@pobox.suse.cz>
Date:	Fri, 29 Jan 2016 20:25:15 +0100 (CET)
From:	Miroslav Benes <mbenes@...e.cz>
To:	Josh Poimboeuf <jpoimboe@...hat.com>
cc:	Steven Rostedt <rostedt@...dmis.org>, Jessica Yu <jeyu@...hat.com>,
	Seth Jennings <sjenning@...hat.com>,
	Jiri Kosina <jikos@...nel.org>,
	Vojtech Pavlik <vojtech@...e.com>,
	Ingo Molnar <mingo@...hat.com>, live-patching@...r.kernel.org,
	linux-kernel@...r.kernel.org, Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [PATCH 1/2] livepatch: Implement separate coming and going module
 notifiers

On Fri, 29 Jan 2016, Josh Poimboeuf wrote:

> On Fri, Jan 29, 2016 at 12:40:14PM -0500, Steven Rostedt wrote:
> > [ Added Rusty, as he's still maintainer of the module code ]
> > 
> > On Fri, 29 Jan 2016 11:30:10 -0600
> > Josh Poimboeuf <jpoimboe@...hat.com> wrote:
> > 
> > > 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;
> > > +	}
> > > +
> > >  	blocking_notifier_call_chain(&module_notify_list,
> > >  				     MODULE_STATE_COMING, mod);
> > >  	return 0;
> > > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> > > index eca592f..c42cf37 100644
> > > --- a/kernel/trace/ftrace.c
> > > +++ b/kernel/trace/ftrace.c
> > > @@ -5045,9 +5045,6 @@ static int ftrace_module_notify(struct notifier_block *self,
> > >  	struct module *mod = data;
> > >  
> > >  	switch (val) {
> > > -	case MODULE_STATE_COMING:
> > > -		ftrace_module_enable(mod);
> > > -		break;
> > >  	case MODULE_STATE_GOING:
> > >  		ftrace_release_mod(mod);
> > >  		break;
> > 
> > If we end up doing something like this, I would just say punt and have
> > the ftrace code be hardcoded into the module code and remove the
> > notifiers completely. ftrace (and live kernel patching for that matter)
> > are rather special. They are not a filesystem or driver. They are core
> > utilities and having them called directly from the module code may be
> > prudent and better to understand and control.
> 
> Agreed, and we might as well make this change now to avoid more churn
> later.

It is possible to achieve the same goal even with the notifiers. They are 
processed synchronously in complete_formation(). So we can put our klp 
hook after that, right? Or better, put it to load_module() after 
complete_formation() call. There is an error handling code even today 
(that is, parse_args() or mod_sysfs_setup() can fail). Moreover, we'll 
have a hook there with Jessica's relocation rework patch set.

But Steven's reasoning is convincing, so I'm all up for it.

Regards,
Miroslav