linux-kernel - Re: Why do kprobes and uprobes singlestep?

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: <CALCETrWoKh0aemrvTGZ13bUzN27s3WGW3CyvTptvayWLQEk91Q@mail.gmail.com>
Date:   Wed, 24 Feb 2021 11:45:10 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     Masami Hiramatsu <mhiramat@...nel.org>
Cc:     Andy Lutomirski <luto@...nel.org>, Oleg Nesterov <oleg@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Anil S Keshavamurthy <anil.s.keshavamurthy@...el.com>,
        "David S. Miller" <davem@...emloft.net>, X86 ML <x86@...nel.org>,
        Andrew Cooper <andrew.cooper3@...rix.com>
Subject: Re: Why do kprobes and uprobes singlestep?

On Tue, Feb 23, 2021 at 5:18 PM Masami Hiramatsu <mhiramat@...nel.org> wrote:
>
> On Tue, 23 Feb 2021 15:24:19 -0800
> Andy Lutomirski <luto@...nel.org> wrote:
>
> > 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.
>
> Would you mean using "pop regs + popf + ret" instead of IRET after
> int3 handled for avoiding IRET releasing the NMI mask? Yeah, it is
> possible. I don't complain about that.

Yes, more or less.

>
> However, what is the relationship between the IRET and single-stepping?
> I think we can do same thing in do_debug...

Because there is no way to single-step without using IRET.  POPF; RET
will trap after RET and you won't make forward progress.

>
> > 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.
>
> For kprobes, there are 2 major reasons for (still relaying on) single stepping.
> One is to provide post_handler, another is executing the original code,
> which is replaced by int3, without modifying code nor emulation.

I don't follow.  Suppose we execute out of line.  If we originally have:

INSN

we replace it with:

INT3

and we have, out of line:

INSN [but with displacement modified if it's RIP-relative]

right now, we single-step the out of line copy.  But couldn't we instead do:

INSN [but with displacement modified if it's RIP-relative]
INT3

or even

INSN [but with displacement modified if it's RIP-relative]
JMP kprobe_post_handler

and avoid single-stepping?

I guess I see the point for CALL, JMP and RET, but it seems like we
could emulate those cases instead fairly easily.