linux-kernel - Re: [PATCH] riscv: provide riscv-specific is_trap

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: <874jkjl4e1.fsf@all.your.base.are.belong.to.us>
Date:   Mon, 28 Aug 2023 14:48:06 +0200
From:   Björn Töpel <bjorn@...nel.org>
To:     Nam Cao <namcaov@...il.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
        guoren@...nel.org
Cc:     Nam Cao <namcaov@...il.com>
Subject: Re: [PATCH] riscv: provide riscv-specific is_trap_insn()

Nam Cao <namcaov@...il.com> writes:

> uprobes expects is_trap_insn() to return true for any trap instructions,
> not just the one used for installing uprobe. The current default
> implementation only returns true for 16-bit c.ebreak if C extension is
> enabled. This can confuse uprobes if a 32-bit ebreak generates a trap
> exception from userspace: uprobes asks is_trap_insn() who says there is no
> trap, so uprobes assume a probe was there before but has been removed, and
> return to the trap instruction. This cause an infinite loop of entering
> and exiting trap handler.
>
> Instead of using the default implementation, implement this function
> speficially for riscv which checks for both ebreak and c.ebreak.

I took this for a spin, and it indeed fixes this new hang! Nice!

However, when I tried setting an uprobe on the ebreak instruction
(offset 0x118) from your example [1], the probe does not show up in the
trace buffer.

Any ideas?

Regardless, your patch fixes the hang:

Tested-by: Björn Töpel <bjorn@...osinc.com>

[1] https://lore.kernel.org/linux-riscv/ZOum50Py8Vki+Nd3@nam-dell/