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+sZ8B-K6KP_W+HOkjCC+7C-YmMyLVVcJv-w1PDR+ZZedfTUPQ@mail.gmail.com>
Date:   Wed, 30 Aug 2023 09:56:37 +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:46 AM Nam Cao <namcaov@...il.com> wrote:
>
> 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.

Oh wait, ignore that, just tested, this is also not checked.

> The actual checks for the validity of the instruction is not done
> until installation.
>
> Best regards,
> Nam