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: <ZOyhozSq3S36eRSq@nam-dell>
Date:   Mon, 28 Aug 2023 15:31:15 +0200
From:   Nam Cao <namcaov@...il.com>
To:     Björn Töpel <bjorn@...nel.org>
Cc:     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
Subject: Re: [PATCH] riscv: provide riscv-specific is_trap_insn()

On Mon, Aug 28, 2023 at 02:48:06PM +0200, Björn Töpel wrote:
> 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!

Great! Thanks for testing it.
 
> 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?

>From my understanding, both uprobes and kprobes refuse to install break points
into existing trap instructions. Otherwise, we may conflict with something else
that is also using trap instructions.

Best regards,
Nam