Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
From:   Andy Lutomirski <luto@kernel.org>
Date:   Tue, 23 Feb 2021 15:24:19 -0800
Message-ID: <CALCETrXzXv-V3A3SpN_Pdj_PNG8Gw0AVsZD7+VO-q_xCAu2T2A@mail.gmail.com>
Subject: Why do kprobes and uprobes singlestep?
To:     Oleg Nesterov <oleg@redhat.com>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>,
        "David S. Miller" <davem@davemloft.net>, X86 ML <x86@kernel.org>,
        Andrew Cooper <andrew.cooper3@citrix.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

A while back, I let myself be convinced that kprobes genuinely need to
single-step the kernel on occasion, and I decided that this sucked but
I could live with it.  it would, however, be Really Really Nice (tm)
if we could have a rule that anyone running x86 Linux who single-steps
the kernel (e.g. kgdb and nothing else) gets to keep all the pieces
when the system falls apart around them.  Specifically, if we don't
allow kernel single-stepping and if we suitably limit kernel
instruction breakpoints (the latter isn't actually a major problem),
then we don't really really need to use IRET to return to the kernel,
and that means we can avoid some massive NMI nastiness.

But I was contemplating the code, and I'm no longer convinced.
Uprobes seem to single-step user code for no discernable reason.
(They want to trap after executing an out of line instruction, AFAICT.
Surely INT3 or even CALL after the out-of-line insn would work as well
or better.)  Why does kprobe single-step?  I spend a while staring at
the code, and it was entirely unclear to me what the purpose of the
single-step is.

--Andy