Re: [PATCH 2/2] livepatch: fix patched module loading race

[Josh Poimboeuf <jpoimboe@redhat.com>]

On Wed, Mar 04, 2015 at 05:36:11PM +0100, Petr Mladek wrote:
> For example, let's have three patches (P1, P2, P3) for the functions a() and b()
> where a() is from vmcore and b() is from a module M. Something like:
> 
> 	a()	b()
> P1	a1()	b1()
> P2	a2()	b2()
> P3	a3()	b3(3)
> 
> If you load the module M after all patches are registered and enabled.
> The ftrace ops for function a() and b() has listed the functions in this
> order
> 
> 	ops_a->func_stack -> list(a3,a2,a1)
> 	ops_b->func_stack -> list(b3,b2,b1)
> 
> , so the pointer to b3() is the first and will be used.
> 
> Then you might have the following scenario. Let's start with state
> when patches P1 and P2 are registered and enabled but the module M
> is not loaded. Then ftrace ops for b() does not exist. Then we
> get into the following race:
> 
> 
> CPU0					CPU1
> 
> load_module(M)
> 
>   complete_formation()
> 
>   mod->state = MODULE_STATE_COMING;
>   mutex_unlock(&module_mutex);
> 
> 					klp_register_patch(P3);
> 					klp_enable_patch(P3);
> 
> 					# STATE 1
> 
> 
>   klp_module_notify(M)
>     klp_module_notify_coming(P1);
>     klp_module_notify_coming(P2);
>     klp_module_notify_coming(P3);
> 
> 					# STATE 2
> 
> 
> The ftrace ops for a() and b() then looks:
> 
>   STATE1:
> 
> 	ops_a->func_stack -> list(a3,a2,a1);
> 	ops_b->func_stack -> list(b3);
> 
>   STATE2:
> 	ops_a->func_stack -> list(a3,a2,a1);
> 	ops_b->func_stack -> list(b2,b1,b3);
> 
> therefore, b2() is used for the module but a3() is used for vmcore
> because they were the last added.

Thanks for the excellent explanation.  That makes sense.

> My plan is to fix this problem by calling klp_module_init() directly
> in load_module() just after ftrace_module_init(). It will solve this
> problem because it will be called in MODULE_STATE_UNFORMED.

Ok, looking forward to that.

> It will have another big advantage. It will allow to pass the error
> code and refuse loading modules that could not get patched. This will
> be needed for the more complex patches anyway. We have to prevent
> running module code that is inconsistent with the patched system.

Yeah, that does need to be fixed up too.

> I am still in doubts how to best solve the problem for going modules.
> Your suggested solution is fine for now. But we will need a better fix
> after adding the more complex consistency model.

Well, we could just get a reference on all patched modules to prevent them
from being unloaded.

-- 
Josh