All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nam Cao <namcaov@gmail.com>
To: Conor Dooley <conor.dooley@microchip.com>
Cc: Guo Ren <guoren@kernel.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	bjorn@kernel.org
Subject: Re: [PATCH] riscv: provide riscv-specific is_trap_insn()
Date: Tue, 29 Aug 2023 10:18:30 +0200	[thread overview]
Message-ID: <ZO2p1tScBT1UFMh1@nam-dell> (raw)
In-Reply-To: <20230829-unbridle-condense-2fc45a442bb6@wendy>

On Tue, Aug 29, 2023 at 07:26:54AM +0100, Conor Dooley wrote:
> On Tue, Aug 29, 2023 at 01:56:34PM +0800, Guo Ren wrote:
> > On Mon, Aug 28, 2023 at 4:56 AM Nam Cao <namcaov@gmail.com> wrote:
> > >
> > > 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.
> > >
> > > Fixes: 74784081aac8 ("riscv: Add uprobes supported")
> > > Signed-off-by: Nam Cao <namcaov@gmail.com>
> > > ---
> > >  arch/riscv/kernel/probes/uprobes.c | 10 ++++++++++
> > >  1 file changed, 10 insertions(+)
> > >
> > > diff --git a/arch/riscv/kernel/probes/uprobes.c b/arch/riscv/kernel/probes/uprobes.c
> > > index 194f166b2cc4..91f4ce101cd1 100644
> > > --- a/arch/riscv/kernel/probes/uprobes.c
> > > +++ b/arch/riscv/kernel/probes/uprobes.c
> > > @@ -3,6 +3,7 @@
> > >  #include <linux/highmem.h>
> > >  #include <linux/ptrace.h>
> > >  #include <linux/uprobes.h>
> > > +#include <asm/insn.h>
> > >
> > >  #include "decode-insn.h"
> > >
> > > @@ -17,6 +18,15 @@ bool is_swbp_insn(uprobe_opcode_t *insn)
> > >  #endif
> > >  }
> >  >
> > > +bool is_trap_insn(uprobe_opcode_t *insn)
> > > +{
> > > +#ifdef CONFIG_RISCV_ISA_C
> 
> > Can we remove the CONFIG_RISCV_ISA_C? As you said, "uprobes expects
> > is_trap_insn() to return true for any trap instructions". So userspace
> > wouldn't be limited by CONFIG_RISCV_ISA_C.
> 
> Isn't the RISCV_ISA_C required because there's a different encoding for
> EBREAK vs C_EBREAK? That said, this should be using IS_ENABLED() not
> #ifdef, since the definition for riscv_insn_is_c_ebreak() is provided
> unconditionally afaict.

Sorry, was too quick that I missed the last sentence.

Now I'm not sure what you mean. But I agree with Guo Ren here, users can use
compressed instructions but kernel does not have it enabled. So we should
always check c.ebreak regardless of RISCV_ISA_C.

Best regards,
Nam

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Nam Cao <namcaov@gmail.com>
To: Conor Dooley <conor.dooley@microchip.com>
Cc: Guo Ren <guoren@kernel.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	bjorn@kernel.org
Subject: Re: [PATCH] riscv: provide riscv-specific is_trap_insn()
Date: Tue, 29 Aug 2023 10:18:30 +0200	[thread overview]
Message-ID: <ZO2p1tScBT1UFMh1@nam-dell> (raw)
In-Reply-To: <20230829-unbridle-condense-2fc45a442bb6@wendy>

On Tue, Aug 29, 2023 at 07:26:54AM +0100, Conor Dooley wrote:
> On Tue, Aug 29, 2023 at 01:56:34PM +0800, Guo Ren wrote:
> > On Mon, Aug 28, 2023 at 4:56 AM Nam Cao <namcaov@gmail.com> wrote:
> > >
> > > 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.
> > >
> > > Fixes: 74784081aac8 ("riscv: Add uprobes supported")
> > > Signed-off-by: Nam Cao <namcaov@gmail.com>
> > > ---
> > >  arch/riscv/kernel/probes/uprobes.c | 10 ++++++++++
> > >  1 file changed, 10 insertions(+)
> > >
> > > diff --git a/arch/riscv/kernel/probes/uprobes.c b/arch/riscv/kernel/probes/uprobes.c
> > > index 194f166b2cc4..91f4ce101cd1 100644
> > > --- a/arch/riscv/kernel/probes/uprobes.c
> > > +++ b/arch/riscv/kernel/probes/uprobes.c
> > > @@ -3,6 +3,7 @@
> > >  #include <linux/highmem.h>
> > >  #include <linux/ptrace.h>
> > >  #include <linux/uprobes.h>
> > > +#include <asm/insn.h>
> > >
> > >  #include "decode-insn.h"
> > >
> > > @@ -17,6 +18,15 @@ bool is_swbp_insn(uprobe_opcode_t *insn)
> > >  #endif
> > >  }
> >  >
> > > +bool is_trap_insn(uprobe_opcode_t *insn)
> > > +{
> > > +#ifdef CONFIG_RISCV_ISA_C
> 
> > Can we remove the CONFIG_RISCV_ISA_C? As you said, "uprobes expects
> > is_trap_insn() to return true for any trap instructions". So userspace
> > wouldn't be limited by CONFIG_RISCV_ISA_C.
> 
> Isn't the RISCV_ISA_C required because there's a different encoding for
> EBREAK vs C_EBREAK? That said, this should be using IS_ENABLED() not
> #ifdef, since the definition for riscv_insn_is_c_ebreak() is provided
> unconditionally afaict.

Sorry, was too quick that I missed the last sentence.

Now I'm not sure what you mean. But I agree with Guo Ren here, users can use
compressed instructions but kernel does not have it enabled. So we should
always check c.ebreak regardless of RISCV_ISA_C.

Best regards,
Nam

  parent reply	other threads:[~2023-08-29  8:18 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-27 20:56 [PATCH] riscv: provide riscv-specific is_trap_insn() Nam Cao
2023-08-27 20:56 ` Nam Cao
2023-08-28 12:48 ` Björn Töpel
2023-08-28 12:48   ` Björn Töpel
2023-08-28 13:31   ` Nam Cao
2023-08-28 13:31     ` Nam Cao
2023-08-28 13:50     ` Nam Cao
2023-08-28 13:50       ` Nam Cao
2023-08-29  6:14       ` Björn Töpel
2023-08-29  6:14         ` Björn Töpel
2023-08-29 18:54         ` Nam Cao
2023-08-29 18:54           ` Nam Cao
2023-08-30  7:32           ` Björn Töpel
2023-08-30  7:32             ` Björn Töpel
2023-08-30  7:46             ` Nam Cao
2023-08-30  7:46               ` Nam Cao
2023-08-30  7:56               ` Nam Cao
2023-08-30  7:56                 ` Nam Cao
2023-08-29  5:56 ` Guo Ren
2023-08-29  5:56   ` Guo Ren
2023-08-29  6:26   ` Conor Dooley
2023-08-29  6:26     ` Conor Dooley
2023-08-29  8:12     ` Nam Cao
2023-08-29  8:12       ` Nam Cao
2023-08-29  8:18     ` Nam Cao [this message]
2023-08-29  8:18       ` Nam Cao
2023-08-31 16:29       ` Conor Dooley
2023-08-31 16:29         ` Conor Dooley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZO2p1tScBT1UFMh1@nam-dell \
    --to=namcaov@gmail.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=bjorn@kernel.org \
    --cc=conor.dooley@microchip.com \
    --cc=guoren@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.