linux-kernel - Re: [PATCH 2/2] x86/entry: Fix unwinding from kprobe on PUSH/POP instruction

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]

Date:   Thu, 16 Feb 2023 08:58:36 -0800
From:   Josh Poimboeuf <jpoimboe@...nel.org>
To:     Masami Hiramatsu <mhiramat@...nel.org>
Cc:     Peter Zijlstra <peterz@...radead.org>, x86@...nel.org,
        linux-kernel@...r.kernel.org,
        Chen Zhongjin <chenzhongjin@...wei.com>,
        "Naveen N. Rao" <naveen.n.rao@...ux.ibm.com>,
        Anil S Keshavamurthy <anil.s.keshavamurthy@...el.com>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH 2/2] x86/entry: Fix unwinding from kprobe on PUSH/POP
 instruction

On Thu, Feb 16, 2023 at 11:35:19PM +0900, Masami Hiramatsu wrote:
> > It could be I'm just confusing things... when #DB traps it is actually
> > because the instruction is complete, so looking up the ORC based on the
> > next instruction is correct, while when #DB faults, it is because the
> > instruction has not yet completed and again ORC lookup on IP just works.
> > 
> > So while determining if #DB is trap or fault is a giant pain in the
> > arse, it does not actually matter for the unwinder in this case.
> > 
> > And with the INT3 thing the problem is that we've replaced an
> > instruction that was supposed to do a stack op.
> > 
> 
> If the kprobe checks whether the original instruction do a stack op and
> if so, setting a flag on current_kprobe will help unwinder finds that case?
> 
> Of course all INT3 user may need to do this but it should be limited.

No, for INT3, even if the original instruction wasn't a stack op, we can
treat it the same way.  Either way, we know the instruction hasn't
executed so we can still use that address to look up the ORC entry.

-- 
Josh