Re: [RFC PATCH 0/1] x86/ftrace: fix live patching vs. tracing race

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 26 Jul 2018 12:40:28 +0200
Nicolai Stange <nstange@suse.de> wrote:

> Hi,
> 
> if a user starts to trace a live patched function, its mcount call will get
> redirected from a trampoline to ftrace_regs_caller.
> 
> In preparation for that, ftrace on x86 first installs an int3 insn at that
> call site.
> 
> ftrace_int3_handler() in turn simply skips over the mcount call insn,
> effectively reverting the livepatch for that function during
> ftrace_replace_code().
> 
> This breaks KLP's consistency model.
> 
> 
> There are two possible options for fixing this:
> 1.) At the ftrace level.
> 2.) Search for a matching klp_ops from ftrace_int3_handler() and
>     handle the redirection if needed.
> 
> Both have their drawbacks, hence the RFC mode for this patch implementing
> 1.).
> 
> The main disadvantage is that it doesn't work on 32 bits (c.f. the patch
> description), but for KLP this would be fine.
> 
> OTOH, it keeps KLP specific code out of ftrace_int3_handler() and might
> perhaps be beneficial in other contexts as well.
> 
> Thanks for your comments!

Thanks, I need to revisit this code. I have ideas that would fix this
problem and improve the live patching code generally.

I'm hoping to get to this within the next month.

-- Steve

> 
> Nicolai
> 
> Nicolai Stange (1):
>   x86/ftrace: make ftrace_int3_handler() not to skip fops invocation
> 
>  arch/x86/kernel/ftrace.c    | 48 ++++++++++++++++++++++++++++++++------
>  arch/x86/kernel/ftrace_64.S | 56 +++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 97 insertions(+), 7 deletions(-)
>