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: <CA+sZ8B8uMqYOE56T3TqDnGGyaEo+sffC_7rWFH78M8OsWc6BSg@mail.gmail.com>
Date:   Wed, 30 Aug 2023 09:46:54 +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 Wed, Aug 30, 2023 at 9:32 AM Björn Töpel <bjorn@...nel.org> wrote:
>
> Nam Cao <namcaov@...il.com> writes:
>
> > On Tue, Aug 29, 2023 at 08:14:59AM +0200, Björn Töpel wrote:
> >> Nam Cao <namcaov@...il.com> writes:
> >>
> >> > On Mon, Aug 28, 2023 at 03:31:15PM +0200, Nam Cao wrote:
> >> >> 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.
> >> >
> >> > I just realize you probably ask this because uprobe can still be installed before
> >> > applying the patch. But I think that is another bug that my patch also
> >> > accidentally fix: uprobes should not install breakpoint into ebreak instructions,
> >> > but it incorrectly does so because it does not even know about the existence of
> >> > 32-bit ebreak.
> >>
> >> FWIW, I can still install the uprobe at an ebreak with you patch. It's
> >> not hit, but succeeds to install.
> >
> > It seems uprobes install failures are completely silent (see uprobe_mmap() in
> > kernel/events/uprobes.c). So I think although uprobes install seems fine, it
> > actually is not.
>
> Huh, so there's no check if the instruction is a valid one at event
> register point?

There are some checks (eg. if the probe is within the binary), but
they are not complete.

The actual checks for the validity of the instruction is not done
until installation.

Best regards,
Nam