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: <20180726102317.550c986d@gandalf.local.home>
Date:   Thu, 26 Jul 2018 10:23:17 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Nicolai Stange <nstange@...e.de>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Jiri Kosina <jikos@...nel.org>,
        Miroslav Benes <mbenes@...e.cz>,
        Petr Mladek <pmladek@...e.com>, live-patching@...r.kernel.org,
        x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/1] x86/ftrace: fix live patching vs. tracing race

On Thu, 26 Jul 2018 12:40:28 +0200
Nicolai Stange <nstange@...e.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(-)
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ