linux-kernel - 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-next>] [day] [month] [year] [list]

Message-ID: <20160824011300.GA31704@packer-debian-8-amd64.digitalocean.com>
Date:   Tue, 23 Aug 2016 21:13:00 -0400
From:   Jessica Yu <jeyu@...hat.com>
To:     Masami Hiramatsu <mhiramat@...nel.org>,
        Petr Mladek <pmladek@...e.com>
Cc:     live-patching@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: livepatch/kprobes incompatibility

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.

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.

Thanks,
Jessica