* [PATCH] riscv: traps: handle uprobe event in software-check exception @ 2025-03-14 9:26 ` Zong Li 0 siblings, 0 replies; 12+ messages in thread From: Zong Li @ 2025-03-14 9:26 UTC (permalink / raw) To: paul.walmsley, palmer, aou, debug, linux-riscv, linux-kernel; +Cc: Zong Li Handle the uprobe event first before handling the CFI violation in software-check exception handler. Because when the landing pad is activated, if the uprobe point is set at the lpad instruction at the beginning of a function, the system triggers a software-check exception instead of an ebreak exception due to the exception priority, then uprobe can't work successfully. Co-developed-by: Deepak Gupta <debug@rivosinc.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Signed-off-by: Zong Li <zong.li@sifive.com> --- This patch is based on top of the following series [PATCH v11 00/27] riscv control-flow integrity for usermode arch/riscv/kernel/traps.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c index 3f7709f4595a..ef5a92111ee1 100644 --- a/arch/riscv/kernel/traps.c +++ b/arch/riscv/kernel/traps.c @@ -386,9 +386,12 @@ asmlinkage __visible __trap_section void do_trap_software_check(struct pt_regs * if (user_mode(regs)) { irqentry_enter_from_user_mode(regs); - /* not a cfi violation, then merge into flow of unknown trap handler */ - if (!handle_user_cfi_violation(regs)) - do_trap_unknown(regs); + /* handle uprobe event frist */ + if (!probe_breakpoint_handler(regs)) { + /* not a cfi violation, then merge into flow of unknown trap handler */ + if (!handle_user_cfi_violation(regs)) + do_trap_unknown(regs); + } irqentry_exit_to_user_mode(regs); } else { -- 2.17.1 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH] riscv: traps: handle uprobe event in software-check exception @ 2025-03-14 9:26 ` Zong Li 0 siblings, 0 replies; 12+ messages in thread From: Zong Li @ 2025-03-14 9:26 UTC (permalink / raw) To: paul.walmsley, palmer, aou, debug, linux-riscv, linux-kernel; +Cc: Zong Li Handle the uprobe event first before handling the CFI violation in software-check exception handler. Because when the landing pad is activated, if the uprobe point is set at the lpad instruction at the beginning of a function, the system triggers a software-check exception instead of an ebreak exception due to the exception priority, then uprobe can't work successfully. Co-developed-by: Deepak Gupta <debug@rivosinc.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Signed-off-by: Zong Li <zong.li@sifive.com> --- This patch is based on top of the following series [PATCH v11 00/27] riscv control-flow integrity for usermode arch/riscv/kernel/traps.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c index 3f7709f4595a..ef5a92111ee1 100644 --- a/arch/riscv/kernel/traps.c +++ b/arch/riscv/kernel/traps.c @@ -386,9 +386,12 @@ asmlinkage __visible __trap_section void do_trap_software_check(struct pt_regs * if (user_mode(regs)) { irqentry_enter_from_user_mode(regs); - /* not a cfi violation, then merge into flow of unknown trap handler */ - if (!handle_user_cfi_violation(regs)) - do_trap_unknown(regs); + /* handle uprobe event frist */ + if (!probe_breakpoint_handler(regs)) { + /* not a cfi violation, then merge into flow of unknown trap handler */ + if (!handle_user_cfi_violation(regs)) + do_trap_unknown(regs); + } irqentry_exit_to_user_mode(regs); } else { -- 2.17.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH] riscv: traps: handle uprobe event in software-check exception 2025-03-14 9:26 ` Zong Li @ 2025-03-25 9:42 ` Alexandre Ghiti -1 siblings, 0 replies; 12+ messages in thread From: Alexandre Ghiti @ 2025-03-25 9:42 UTC (permalink / raw) To: Zong Li, paul.walmsley, palmer, aou, debug, linux-riscv, linux-kernel Hi, On 14/03/2025 10:26, Zong Li wrote: > Handle the uprobe event first before handling the CFI violation in > software-check exception handler. Because when the landing pad is > activated, if the uprobe point is set at the lpad instruction at > the beginning of a function, the system triggers a software-check > exception instead of an ebreak exception due to the exception > priority, then uprobe can't work successfully. > > Co-developed-by: Deepak Gupta <debug@rivosinc.com> > Signed-off-by: Deepak Gupta <debug@rivosinc.com> > Signed-off-by: Zong Li <zong.li@sifive.com> > --- > > This patch is based on top of the following series > [PATCH v11 00/27] riscv control-flow integrity for usermode > > arch/riscv/kernel/traps.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c > index 3f7709f4595a..ef5a92111ee1 100644 > --- a/arch/riscv/kernel/traps.c > +++ b/arch/riscv/kernel/traps.c > @@ -386,9 +386,12 @@ asmlinkage __visible __trap_section void do_trap_software_check(struct pt_regs * > if (user_mode(regs)) { > irqentry_enter_from_user_mode(regs); > > - /* not a cfi violation, then merge into flow of unknown trap handler */ > - if (!handle_user_cfi_violation(regs)) > - do_trap_unknown(regs); > + /* handle uprobe event frist */ > + if (!probe_breakpoint_handler(regs)) { > + /* not a cfi violation, then merge into flow of unknown trap handler */ > + if (!handle_user_cfi_violation(regs)) > + do_trap_unknown(regs); > + } > > irqentry_exit_to_user_mode(regs); > } else { Deepak, can you take this patch in your next spin of your CFI series? Otherwise, I'm pretty sure we will forget about it :) Thanks, Alex _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] riscv: traps: handle uprobe event in software-check exception @ 2025-03-25 9:42 ` Alexandre Ghiti 0 siblings, 0 replies; 12+ messages in thread From: Alexandre Ghiti @ 2025-03-25 9:42 UTC (permalink / raw) To: Zong Li, paul.walmsley, palmer, aou, debug, linux-riscv, linux-kernel Hi, On 14/03/2025 10:26, Zong Li wrote: > Handle the uprobe event first before handling the CFI violation in > software-check exception handler. Because when the landing pad is > activated, if the uprobe point is set at the lpad instruction at > the beginning of a function, the system triggers a software-check > exception instead of an ebreak exception due to the exception > priority, then uprobe can't work successfully. > > Co-developed-by: Deepak Gupta <debug@rivosinc.com> > Signed-off-by: Deepak Gupta <debug@rivosinc.com> > Signed-off-by: Zong Li <zong.li@sifive.com> > --- > > This patch is based on top of the following series > [PATCH v11 00/27] riscv control-flow integrity for usermode > > arch/riscv/kernel/traps.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c > index 3f7709f4595a..ef5a92111ee1 100644 > --- a/arch/riscv/kernel/traps.c > +++ b/arch/riscv/kernel/traps.c > @@ -386,9 +386,12 @@ asmlinkage __visible __trap_section void do_trap_software_check(struct pt_regs * > if (user_mode(regs)) { > irqentry_enter_from_user_mode(regs); > > - /* not a cfi violation, then merge into flow of unknown trap handler */ > - if (!handle_user_cfi_violation(regs)) > - do_trap_unknown(regs); > + /* handle uprobe event frist */ > + if (!probe_breakpoint_handler(regs)) { > + /* not a cfi violation, then merge into flow of unknown trap handler */ > + if (!handle_user_cfi_violation(regs)) > + do_trap_unknown(regs); > + } > > irqentry_exit_to_user_mode(regs); > } else { Deepak, can you take this patch in your next spin of your CFI series? Otherwise, I'm pretty sure we will forget about it :) Thanks, Alex ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] riscv: traps: handle uprobe event in software-check exception 2025-03-14 9:26 ` Zong Li @ 2025-06-02 16:49 ` Deepak Gupta -1 siblings, 0 replies; 12+ messages in thread From: Deepak Gupta @ 2025-06-02 16:49 UTC (permalink / raw) To: Zong Li; +Cc: paul.walmsley, palmer, aou, linux-riscv, linux-kernel Hi Zong, Thanks for taking the initiative for making cfi work with uprobe. And sorry for not noticing the patch earlier. Few comments inline. On Fri, Mar 14, 2025 at 05:26:14PM +0800, Zong Li wrote: >Handle the uprobe event first before handling the CFI violation in >software-check exception handler. Because when the landing pad is >activated, if the uprobe point is set at the lpad instruction at >the beginning of a function, the system triggers a software-check >exception instead of an ebreak exception due to the exception >priority, then uprobe can't work successfully. > >Co-developed-by: Deepak Gupta <debug@rivosinc.com> >Signed-off-by: Deepak Gupta <debug@rivosinc.com> >Signed-off-by: Zong Li <zong.li@sifive.com> >--- > >This patch is based on top of the following series >[PATCH v11 00/27] riscv control-flow integrity for usermode > > arch/riscv/kernel/traps.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > >diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c >index 3f7709f4595a..ef5a92111ee1 100644 >--- a/arch/riscv/kernel/traps.c >+++ b/arch/riscv/kernel/traps.c >@@ -386,9 +386,12 @@ asmlinkage __visible __trap_section void do_trap_software_check(struct pt_regs * > if (user_mode(regs)) { > irqentry_enter_from_user_mode(regs); > >- /* not a cfi violation, then merge into flow of unknown trap handler */ >- if (!handle_user_cfi_violation(regs)) >- do_trap_unknown(regs); >+ /* handle uprobe event frist */ >+ if (!probe_breakpoint_handler(regs)) { If task has uprobe enabled and there is a cfi violation due to mismatch in return address on shadow stack and regular stack, then it would be a cfi bypass, right? Perhaps we should be doing this only when we match that sw check exception is due to forward cfi violation? Do you agree? >+ /* not a cfi violation, then merge into flow of unknown trap handler */ >+ if (!handle_user_cfi_violation(regs)) >+ do_trap_unknown(regs); >+ } > > irqentry_exit_to_user_mode(regs); > } else { >-- >2.17.1 > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] riscv: traps: handle uprobe event in software-check exception @ 2025-06-02 16:49 ` Deepak Gupta 0 siblings, 0 replies; 12+ messages in thread From: Deepak Gupta @ 2025-06-02 16:49 UTC (permalink / raw) To: Zong Li; +Cc: paul.walmsley, palmer, aou, linux-riscv, linux-kernel Hi Zong, Thanks for taking the initiative for making cfi work with uprobe. And sorry for not noticing the patch earlier. Few comments inline. On Fri, Mar 14, 2025 at 05:26:14PM +0800, Zong Li wrote: >Handle the uprobe event first before handling the CFI violation in >software-check exception handler. Because when the landing pad is >activated, if the uprobe point is set at the lpad instruction at >the beginning of a function, the system triggers a software-check >exception instead of an ebreak exception due to the exception >priority, then uprobe can't work successfully. > >Co-developed-by: Deepak Gupta <debug@rivosinc.com> >Signed-off-by: Deepak Gupta <debug@rivosinc.com> >Signed-off-by: Zong Li <zong.li@sifive.com> >--- > >This patch is based on top of the following series >[PATCH v11 00/27] riscv control-flow integrity for usermode > > arch/riscv/kernel/traps.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > >diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c >index 3f7709f4595a..ef5a92111ee1 100644 >--- a/arch/riscv/kernel/traps.c >+++ b/arch/riscv/kernel/traps.c >@@ -386,9 +386,12 @@ asmlinkage __visible __trap_section void do_trap_software_check(struct pt_regs * > if (user_mode(regs)) { > irqentry_enter_from_user_mode(regs); > >- /* not a cfi violation, then merge into flow of unknown trap handler */ >- if (!handle_user_cfi_violation(regs)) >- do_trap_unknown(regs); >+ /* handle uprobe event frist */ >+ if (!probe_breakpoint_handler(regs)) { If task has uprobe enabled and there is a cfi violation due to mismatch in return address on shadow stack and regular stack, then it would be a cfi bypass, right? Perhaps we should be doing this only when we match that sw check exception is due to forward cfi violation? Do you agree? >+ /* not a cfi violation, then merge into flow of unknown trap handler */ >+ if (!handle_user_cfi_violation(regs)) >+ do_trap_unknown(regs); >+ } > > irqentry_exit_to_user_mode(regs); > } else { >-- >2.17.1 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] riscv: traps: handle uprobe event in software-check exception 2025-06-02 16:49 ` Deepak Gupta @ 2025-06-03 1:48 ` Zong Li -1 siblings, 0 replies; 12+ messages in thread From: Zong Li @ 2025-06-03 1:48 UTC (permalink / raw) To: Deepak Gupta; +Cc: paul.walmsley, palmer, aou, linux-riscv, linux-kernel On Tue, Jun 3, 2025 at 12:50 AM Deepak Gupta <debug@rivosinc.com> wrote: > > Hi Zong, > > Thanks for taking the initiative for making cfi work with uprobe. > And sorry for not noticing the patch earlier. > Few comments inline. > > > On Fri, Mar 14, 2025 at 05:26:14PM +0800, Zong Li wrote: > >Handle the uprobe event first before handling the CFI violation in > >software-check exception handler. Because when the landing pad is > >activated, if the uprobe point is set at the lpad instruction at > >the beginning of a function, the system triggers a software-check > >exception instead of an ebreak exception due to the exception > >priority, then uprobe can't work successfully. > > > >Co-developed-by: Deepak Gupta <debug@rivosinc.com> > >Signed-off-by: Deepak Gupta <debug@rivosinc.com> > >Signed-off-by: Zong Li <zong.li@sifive.com> > >--- > > > >This patch is based on top of the following series > >[PATCH v11 00/27] riscv control-flow integrity for usermode > > > > arch/riscv/kernel/traps.c | 9 ++++++--- > > 1 file changed, 6 insertions(+), 3 deletions(-) > > > >diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c > >index 3f7709f4595a..ef5a92111ee1 100644 > >--- a/arch/riscv/kernel/traps.c > >+++ b/arch/riscv/kernel/traps.c > >@@ -386,9 +386,12 @@ asmlinkage __visible __trap_section void do_trap_software_check(struct pt_regs * > > if (user_mode(regs)) { > > irqentry_enter_from_user_mode(regs); > > > >- /* not a cfi violation, then merge into flow of unknown trap handler */ > >- if (!handle_user_cfi_violation(regs)) > >- do_trap_unknown(regs); > >+ /* handle uprobe event frist */ > >+ if (!probe_breakpoint_handler(regs)) { > > If task has uprobe enabled and there is a cfi violation due to mismatch in > return address on shadow stack and regular stack, then it would be a cfi > bypass, right? > Perhaps we should be doing this only when we match that sw check exception > is due to forward cfi violation? > > Do you agree? Yes, let me add a condition for forward cfi violation here. Thanks for pointing it out. > > >+ /* not a cfi violation, then merge into flow of unknown trap handler */ > >+ if (!handle_user_cfi_violation(regs)) > >+ do_trap_unknown(regs); > >+ } > > > > irqentry_exit_to_user_mode(regs); > > } else { > >-- > >2.17.1 > > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] riscv: traps: handle uprobe event in software-check exception @ 2025-06-03 1:48 ` Zong Li 0 siblings, 0 replies; 12+ messages in thread From: Zong Li @ 2025-06-03 1:48 UTC (permalink / raw) To: Deepak Gupta; +Cc: paul.walmsley, palmer, aou, linux-riscv, linux-kernel On Tue, Jun 3, 2025 at 12:50 AM Deepak Gupta <debug@rivosinc.com> wrote: > > Hi Zong, > > Thanks for taking the initiative for making cfi work with uprobe. > And sorry for not noticing the patch earlier. > Few comments inline. > > > On Fri, Mar 14, 2025 at 05:26:14PM +0800, Zong Li wrote: > >Handle the uprobe event first before handling the CFI violation in > >software-check exception handler. Because when the landing pad is > >activated, if the uprobe point is set at the lpad instruction at > >the beginning of a function, the system triggers a software-check > >exception instead of an ebreak exception due to the exception > >priority, then uprobe can't work successfully. > > > >Co-developed-by: Deepak Gupta <debug@rivosinc.com> > >Signed-off-by: Deepak Gupta <debug@rivosinc.com> > >Signed-off-by: Zong Li <zong.li@sifive.com> > >--- > > > >This patch is based on top of the following series > >[PATCH v11 00/27] riscv control-flow integrity for usermode > > > > arch/riscv/kernel/traps.c | 9 ++++++--- > > 1 file changed, 6 insertions(+), 3 deletions(-) > > > >diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c > >index 3f7709f4595a..ef5a92111ee1 100644 > >--- a/arch/riscv/kernel/traps.c > >+++ b/arch/riscv/kernel/traps.c > >@@ -386,9 +386,12 @@ asmlinkage __visible __trap_section void do_trap_software_check(struct pt_regs * > > if (user_mode(regs)) { > > irqentry_enter_from_user_mode(regs); > > > >- /* not a cfi violation, then merge into flow of unknown trap handler */ > >- if (!handle_user_cfi_violation(regs)) > >- do_trap_unknown(regs); > >+ /* handle uprobe event frist */ > >+ if (!probe_breakpoint_handler(regs)) { > > If task has uprobe enabled and there is a cfi violation due to mismatch in > return address on shadow stack and regular stack, then it would be a cfi > bypass, right? > Perhaps we should be doing this only when we match that sw check exception > is due to forward cfi violation? > > Do you agree? Yes, let me add a condition for forward cfi violation here. Thanks for pointing it out. > > >+ /* not a cfi violation, then merge into flow of unknown trap handler */ > >+ if (!handle_user_cfi_violation(regs)) > >+ do_trap_unknown(regs); > >+ } > > > > irqentry_exit_to_user_mode(regs); > > } else { > >-- > >2.17.1 > > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] riscv: traps: handle uprobe event in software-check exception 2025-06-03 1:48 ` Zong Li @ 2025-06-04 1:06 ` Deepak Gupta -1 siblings, 0 replies; 12+ messages in thread From: Deepak Gupta @ 2025-06-04 1:06 UTC (permalink / raw) To: Zong Li; +Cc: paul.walmsley, palmer, aou, linux-riscv, linux-kernel On Tue, Jun 03, 2025 at 09:48:08AM +0800, Zong Li wrote: >On Tue, Jun 3, 2025 at 12:50 AM Deepak Gupta <debug@rivosinc.com> wrote: >> >> Hi Zong, >> >> Thanks for taking the initiative for making cfi work with uprobe. >> And sorry for not noticing the patch earlier. >> Few comments inline. >> >> >> On Fri, Mar 14, 2025 at 05:26:14PM +0800, Zong Li wrote: >> >Handle the uprobe event first before handling the CFI violation in >> >software-check exception handler. Because when the landing pad is >> >activated, if the uprobe point is set at the lpad instruction at >> >the beginning of a function, the system triggers a software-check >> >exception instead of an ebreak exception due to the exception >> >priority, then uprobe can't work successfully. >> > >> >Co-developed-by: Deepak Gupta <debug@rivosinc.com> >> >Signed-off-by: Deepak Gupta <debug@rivosinc.com> >> >Signed-off-by: Zong Li <zong.li@sifive.com> >> >--- >> > >> >This patch is based on top of the following series >> >[PATCH v11 00/27] riscv control-flow integrity for usermode >> > >> > arch/riscv/kernel/traps.c | 9 ++++++--- >> > 1 file changed, 6 insertions(+), 3 deletions(-) >> > >> >diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c >> >index 3f7709f4595a..ef5a92111ee1 100644 >> >--- a/arch/riscv/kernel/traps.c >> >+++ b/arch/riscv/kernel/traps.c >> >@@ -386,9 +386,12 @@ asmlinkage __visible __trap_section void do_trap_software_check(struct pt_regs * >> > if (user_mode(regs)) { >> > irqentry_enter_from_user_mode(regs); >> > >> >- /* not a cfi violation, then merge into flow of unknown trap handler */ >> >- if (!handle_user_cfi_violation(regs)) >> >- do_trap_unknown(regs); >> >+ /* handle uprobe event frist */ >> >+ if (!probe_breakpoint_handler(regs)) { >> >> If task has uprobe enabled and there is a cfi violation due to mismatch in >> return address on shadow stack and regular stack, then it would be a cfi >> bypass, right? >> Perhaps we should be doing this only when we match that sw check exception >> is due to forward cfi violation? >> >> Do you agree? > >Yes, let me add a condition for forward cfi violation here. Thanks for >pointing it out. Cool, I'll send out another revision for my cfi series this week. If you send out your uprobe fix, I can include it in my patchset. > >> >> >+ /* not a cfi violation, then merge into flow of unknown trap handler */ >> >+ if (!handle_user_cfi_violation(regs)) >> >+ do_trap_unknown(regs); >> >+ } >> > >> > irqentry_exit_to_user_mode(regs); >> > } else { >> >-- >> >2.17.1 >> > >> >> _______________________________________________ >> linux-riscv mailing list >> linux-riscv@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-riscv _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] riscv: traps: handle uprobe event in software-check exception @ 2025-06-04 1:06 ` Deepak Gupta 0 siblings, 0 replies; 12+ messages in thread From: Deepak Gupta @ 2025-06-04 1:06 UTC (permalink / raw) To: Zong Li; +Cc: paul.walmsley, palmer, aou, linux-riscv, linux-kernel On Tue, Jun 03, 2025 at 09:48:08AM +0800, Zong Li wrote: >On Tue, Jun 3, 2025 at 12:50 AM Deepak Gupta <debug@rivosinc.com> wrote: >> >> Hi Zong, >> >> Thanks for taking the initiative for making cfi work with uprobe. >> And sorry for not noticing the patch earlier. >> Few comments inline. >> >> >> On Fri, Mar 14, 2025 at 05:26:14PM +0800, Zong Li wrote: >> >Handle the uprobe event first before handling the CFI violation in >> >software-check exception handler. Because when the landing pad is >> >activated, if the uprobe point is set at the lpad instruction at >> >the beginning of a function, the system triggers a software-check >> >exception instead of an ebreak exception due to the exception >> >priority, then uprobe can't work successfully. >> > >> >Co-developed-by: Deepak Gupta <debug@rivosinc.com> >> >Signed-off-by: Deepak Gupta <debug@rivosinc.com> >> >Signed-off-by: Zong Li <zong.li@sifive.com> >> >--- >> > >> >This patch is based on top of the following series >> >[PATCH v11 00/27] riscv control-flow integrity for usermode >> > >> > arch/riscv/kernel/traps.c | 9 ++++++--- >> > 1 file changed, 6 insertions(+), 3 deletions(-) >> > >> >diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c >> >index 3f7709f4595a..ef5a92111ee1 100644 >> >--- a/arch/riscv/kernel/traps.c >> >+++ b/arch/riscv/kernel/traps.c >> >@@ -386,9 +386,12 @@ asmlinkage __visible __trap_section void do_trap_software_check(struct pt_regs * >> > if (user_mode(regs)) { >> > irqentry_enter_from_user_mode(regs); >> > >> >- /* not a cfi violation, then merge into flow of unknown trap handler */ >> >- if (!handle_user_cfi_violation(regs)) >> >- do_trap_unknown(regs); >> >+ /* handle uprobe event frist */ >> >+ if (!probe_breakpoint_handler(regs)) { >> >> If task has uprobe enabled and there is a cfi violation due to mismatch in >> return address on shadow stack and regular stack, then it would be a cfi >> bypass, right? >> Perhaps we should be doing this only when we match that sw check exception >> is due to forward cfi violation? >> >> Do you agree? > >Yes, let me add a condition for forward cfi violation here. Thanks for >pointing it out. Cool, I'll send out another revision for my cfi series this week. If you send out your uprobe fix, I can include it in my patchset. > >> >> >+ /* not a cfi violation, then merge into flow of unknown trap handler */ >> >+ if (!handle_user_cfi_violation(regs)) >> >+ do_trap_unknown(regs); >> >+ } >> > >> > irqentry_exit_to_user_mode(regs); >> > } else { >> >-- >> >2.17.1 >> > >> >> _______________________________________________ >> linux-riscv mailing list >> linux-riscv@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] riscv: traps: handle uprobe event in software-check exception 2025-06-04 1:06 ` Deepak Gupta @ 2025-06-04 9:38 ` Zong Li -1 siblings, 0 replies; 12+ messages in thread From: Zong Li @ 2025-06-04 9:38 UTC (permalink / raw) To: Deepak Gupta; +Cc: paul.walmsley, palmer, aou, linux-riscv, linux-kernel On Wed, Jun 4, 2025 at 9:06 AM Deepak Gupta <debug@rivosinc.com> wrote: > > On Tue, Jun 03, 2025 at 09:48:08AM +0800, Zong Li wrote: > >On Tue, Jun 3, 2025 at 12:50 AM Deepak Gupta <debug@rivosinc.com> wrote: > >> > >> Hi Zong, > >> > >> Thanks for taking the initiative for making cfi work with uprobe. > >> And sorry for not noticing the patch earlier. > >> Few comments inline. > >> > >> > >> On Fri, Mar 14, 2025 at 05:26:14PM +0800, Zong Li wrote: > >> >Handle the uprobe event first before handling the CFI violation in > >> >software-check exception handler. Because when the landing pad is > >> >activated, if the uprobe point is set at the lpad instruction at > >> >the beginning of a function, the system triggers a software-check > >> >exception instead of an ebreak exception due to the exception > >> >priority, then uprobe can't work successfully. > >> > > >> >Co-developed-by: Deepak Gupta <debug@rivosinc.com> > >> >Signed-off-by: Deepak Gupta <debug@rivosinc.com> > >> >Signed-off-by: Zong Li <zong.li@sifive.com> > >> >--- > >> > > >> >This patch is based on top of the following series > >> >[PATCH v11 00/27] riscv control-flow integrity for usermode > >> > > >> > arch/riscv/kernel/traps.c | 9 ++++++--- > >> > 1 file changed, 6 insertions(+), 3 deletions(-) > >> > > >> >diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c > >> >index 3f7709f4595a..ef5a92111ee1 100644 > >> >--- a/arch/riscv/kernel/traps.c > >> >+++ b/arch/riscv/kernel/traps.c > >> >@@ -386,9 +386,12 @@ asmlinkage __visible __trap_section void do_trap_software_check(struct pt_regs * > >> > if (user_mode(regs)) { > >> > irqentry_enter_from_user_mode(regs); > >> > > >> >- /* not a cfi violation, then merge into flow of unknown trap handler */ > >> >- if (!handle_user_cfi_violation(regs)) > >> >- do_trap_unknown(regs); > >> >+ /* handle uprobe event frist */ > >> >+ if (!probe_breakpoint_handler(regs)) { > >> > >> If task has uprobe enabled and there is a cfi violation due to mismatch in > >> return address on shadow stack and regular stack, then it would be a cfi > >> bypass, right? > >> Perhaps we should be doing this only when we match that sw check exception > >> is due to forward cfi violation? > >> > >> Do you agree? > > > >Yes, let me add a condition for forward cfi violation here. Thanks for > >pointing it out. > > Cool, I'll send out another revision for my cfi series this week. > If you send out your uprobe fix, I can include it in my patchset. Hi Deepak, I have submitted the v2 patch. Please let me know if further modifications are required. Thanks https://lists.infradead.org/pipermail/linux-riscv/2025-June/071483.html > > > > >> > >> >+ /* not a cfi violation, then merge into flow of unknown trap handler */ > >> >+ if (!handle_user_cfi_violation(regs)) > >> >+ do_trap_unknown(regs); > >> >+ } > >> > > >> > irqentry_exit_to_user_mode(regs); > >> > } else { > >> >-- > >> >2.17.1 > >> > > >> > >> _______________________________________________ > >> linux-riscv mailing list > >> linux-riscv@lists.infradead.org > >> http://lists.infradead.org/mailman/listinfo/linux-riscv _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] riscv: traps: handle uprobe event in software-check exception @ 2025-06-04 9:38 ` Zong Li 0 siblings, 0 replies; 12+ messages in thread From: Zong Li @ 2025-06-04 9:38 UTC (permalink / raw) To: Deepak Gupta; +Cc: paul.walmsley, palmer, aou, linux-riscv, linux-kernel On Wed, Jun 4, 2025 at 9:06 AM Deepak Gupta <debug@rivosinc.com> wrote: > > On Tue, Jun 03, 2025 at 09:48:08AM +0800, Zong Li wrote: > >On Tue, Jun 3, 2025 at 12:50 AM Deepak Gupta <debug@rivosinc.com> wrote: > >> > >> Hi Zong, > >> > >> Thanks for taking the initiative for making cfi work with uprobe. > >> And sorry for not noticing the patch earlier. > >> Few comments inline. > >> > >> > >> On Fri, Mar 14, 2025 at 05:26:14PM +0800, Zong Li wrote: > >> >Handle the uprobe event first before handling the CFI violation in > >> >software-check exception handler. Because when the landing pad is > >> >activated, if the uprobe point is set at the lpad instruction at > >> >the beginning of a function, the system triggers a software-check > >> >exception instead of an ebreak exception due to the exception > >> >priority, then uprobe can't work successfully. > >> > > >> >Co-developed-by: Deepak Gupta <debug@rivosinc.com> > >> >Signed-off-by: Deepak Gupta <debug@rivosinc.com> > >> >Signed-off-by: Zong Li <zong.li@sifive.com> > >> >--- > >> > > >> >This patch is based on top of the following series > >> >[PATCH v11 00/27] riscv control-flow integrity for usermode > >> > > >> > arch/riscv/kernel/traps.c | 9 ++++++--- > >> > 1 file changed, 6 insertions(+), 3 deletions(-) > >> > > >> >diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c > >> >index 3f7709f4595a..ef5a92111ee1 100644 > >> >--- a/arch/riscv/kernel/traps.c > >> >+++ b/arch/riscv/kernel/traps.c > >> >@@ -386,9 +386,12 @@ asmlinkage __visible __trap_section void do_trap_software_check(struct pt_regs * > >> > if (user_mode(regs)) { > >> > irqentry_enter_from_user_mode(regs); > >> > > >> >- /* not a cfi violation, then merge into flow of unknown trap handler */ > >> >- if (!handle_user_cfi_violation(regs)) > >> >- do_trap_unknown(regs); > >> >+ /* handle uprobe event frist */ > >> >+ if (!probe_breakpoint_handler(regs)) { > >> > >> If task has uprobe enabled and there is a cfi violation due to mismatch in > >> return address on shadow stack and regular stack, then it would be a cfi > >> bypass, right? > >> Perhaps we should be doing this only when we match that sw check exception > >> is due to forward cfi violation? > >> > >> Do you agree? > > > >Yes, let me add a condition for forward cfi violation here. Thanks for > >pointing it out. > > Cool, I'll send out another revision for my cfi series this week. > If you send out your uprobe fix, I can include it in my patchset. Hi Deepak, I have submitted the v2 patch. Please let me know if further modifications are required. Thanks https://lists.infradead.org/pipermail/linux-riscv/2025-June/071483.html > > > > >> > >> >+ /* not a cfi violation, then merge into flow of unknown trap handler */ > >> >+ if (!handle_user_cfi_violation(regs)) > >> >+ do_trap_unknown(regs); > >> >+ } > >> > > >> > irqentry_exit_to_user_mode(regs); > >> > } else { > >> >-- > >> >2.17.1 > >> > > >> > >> _______________________________________________ > >> linux-riscv mailing list > >> linux-riscv@lists.infradead.org > >> http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2025-06-04 9:40 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-03-14 9:26 [PATCH] riscv: traps: handle uprobe event in software-check exception Zong Li 2025-03-14 9:26 ` Zong Li 2025-03-25 9:42 ` Alexandre Ghiti 2025-03-25 9:42 ` Alexandre Ghiti 2025-06-02 16:49 ` Deepak Gupta 2025-06-02 16:49 ` Deepak Gupta 2025-06-03 1:48 ` Zong Li 2025-06-03 1:48 ` Zong Li 2025-06-04 1:06 ` Deepak Gupta 2025-06-04 1:06 ` Deepak Gupta 2025-06-04 9:38 ` Zong Li 2025-06-04 9:38 ` Zong Li
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.