linux-kernel - Re: livepatch/kprobes incompatibility

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: <20160825001646.3c2ee1034b80844d35c8f569@kernel.org>
Date:   Thu, 25 Aug 2016 00:16:46 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     Jessica Yu <jeyu@...hat.com>
Cc:     Petr Mladek <pmladek@...e.com>, live-patching@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: livepatch/kprobes incompatibility

On Tue, 23 Aug 2016 21:13:00 -0400
Jessica Yu <jeyu@...hat.com> wrote:

> Hi Masami, Petr,
> 
> I'm trying to figure out where we are exactly with fixing the problems with
> livepatch + kprobes, and I was wondering if there will be any more updates to
> the ipmodify patchset that was originally merged back in 2014 (See:
> https://lkml.org/lkml/2014/11/20/808). It seems that patch 4/5 ("kprobes: Set
> IPMODIFY flag only if the probe can change regs->ip") wasn't merged due to
> other ongoing work, and this patch in particular was needed to enforce a hard
> conflict between livepatch and jprobes while still enabling livepatch and
> kprobes to co-exist.

Hmm, it seems I have missed to follow it up.
I'll try refresh it for the latest kernel again.

> Currently, it looks like livepatch/kpatch and kprobes are still in direct
> conflict, since both kprobe_ftrace_ops and klp_ops have FTRACE_OPS_FL_IPMODIFY
> set. *But* it seems like this mutual exclusion wasn't 100% implemented; I'm
> not sure if this was intentional, but kprobes registration will still return
> success even when ftrace registration fails due to an ipmodify conflict, and
> instead we just get WARNs (See: arm_kprobe_ftrace()).
> 
> So we still end up with buggy situations like the following:
>    (1) livepatch patches meminfo_proc_show [ succeeds ]
>    (2) systemtap probes meminfo_proc_show (using kprobes) [ fails ]
>        * BUT from the user's perspective, it would look like systemtap succeeded,
>          since register_kprobe() returned success, but the handler will never fire
>          and only when we look at dmesg do we see that something went wrong
>          (i.e. ftrace registration had failed since livepatch already reserved
>          ipmodify in step 1).
> 
> From what I understand though, there was work being planned to limit this
> direct conflict to just livepatch and jprobes, since most of the time kprobes
> doesn't change regs->ip. Just wondering what the current state of this work is.

Right, jprobes and livepatch can not work together, but kprobe should be
available.

Thanks,

-- 
Masami Hiramatsu <mhiramat@...nel.org>