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

From: Josh Poimboeuf
Date: Wed Mar 04 2015 - 12:57:58 EST


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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/