Re: [RFC PATCH 0/1] x86/ftrace: fix live patching vs. tracing race
From: Steven Rostedt
Date: Thu Jul 26 2018 - 10:23:23 EST
On Thu, 26 Jul 2018 12:40:28 +0200
Nicolai Stange <nstange@xxxxxxx> 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(-)
>