linux-kernel - Re: [PATCH v5 2/2] arm64: kgdb: Set PSTATE.SS to 1 to re-enable single-step

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] [day] [month] [year] [list]

Date:   Fri, 27 Jan 2023 18:00:39 +0530
From:   Sumit Garg <sumit.garg@...aro.org>
To:     Will Deacon <will@...nel.org>
Cc:     catalin.marinas@....com, mark.rutland@....com,
        daniel.thompson@...aro.org, dianders@...omium.org,
        liwei391@...wei.com, mhiramat@...nel.org, maz@...nel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 2/2] arm64: kgdb: Set PSTATE.SS to 1 to re-enable single-step

On Fri, 27 Jan 2023 at 17:20, Will Deacon <will@...nel.org> wrote:
>
> On Mon, Dec 19, 2022 at 03:54:52PM +0530, Sumit Garg wrote:
> > Currently only the first attempt to single-step has any effect. After
> > that all further stepping remains "stuck" at the same program counter
> > value.
> >
> > Refer to the ARM Architecture Reference Manual (ARM DDI 0487E.a) D2.12,
> > PSTATE.SS=1 should be set at each step before transferring the PE to the
> > 'Active-not-pending' state. The problem here is PSTATE.SS=1 is not set
> > since the second single-step.
> >
> > After the first single-step, the PE transferes to the 'Inactive' state,
> > with PSTATE.SS=0 and MDSCR.SS=1, thus PSTATE.SS won't be set to 1 due to
> > kernel_active_single_step()=true. Then the PE transferes to the
> > 'Active-pending' state when ERET and returns to the debugger by step
> > exception.
> >
> > Before this patch:
> > ==================
> > Entering kdb (current=0xffff3376039f0000, pid 1) on processor 0 due to Keyboard Entry
> > [0]kdb>
> >
> > [0]kdb>
> > [0]kdb> bp write_sysrq_trigger
> > Instruction(i) BP #0 at 0xffffa45c13d09290 (write_sysrq_trigger)
> >     is enabled   addr at ffffa45c13d09290, hardtype=0 installed=0
> >
> > [0]kdb> go
> > $ echo h > /proc/sysrq-trigger
> >
> > Entering kdb (current=0xffff4f7e453f8000, pid 175) on processor 1 due to Breakpoint @ 0xffffad651a309290
> > [1]kdb> ss
> >
> > Entering kdb (current=0xffff4f7e453f8000, pid 175) on processor 1 due to SS trap @ 0xffffad651a309294
> > [1]kdb> ss
> >
> > Entering kdb (current=0xffff4f7e453f8000, pid 175) on processor 1 due to SS trap @ 0xffffad651a309294
> > [1]kdb>
> >
> > After this patch:
> > =================
> > Entering kdb (current=0xffff6851c39f0000, pid 1) on processor 0 due to Keyboard Entry
> > [0]kdb> bp write_sysrq_trigger
> > Instruction(i) BP #0 at 0xffffc02d2dd09290 (write_sysrq_trigger)
> >     is enabled   addr at ffffc02d2dd09290, hardtype=0 installed=0
> >
> > [0]kdb> go
> > $ echo h > /proc/sysrq-trigger
> >
> > Entering kdb (current=0xffff6851c53c1840, pid 174) on processor 1 due to Breakpoint @ 0xffffc02d2dd09290
> > [1]kdb> ss
> >
> > Entering kdb (current=0xffff6851c53c1840, pid 174) on processor 1 due to SS trap @ 0xffffc02d2dd09294
> > [1]kdb> ss
> >
> > Entering kdb (current=0xffff6851c53c1840, pid 174) on processor 1 due to SS trap @ 0xffffc02d2dd09298
> > [1]kdb> ss
> >
> > Entering kdb (current=0xffff6851c53c1840, pid 174) on processor 1 due to SS trap @ 0xffffc02d2dd0929c
> > [1]kdb>
> >
> > Fixes: 44679a4f142b ("arm64: KGDB: Add step debugging support")
> > Co-developed-by: Wei Li <liwei391@...wei.com>
> > Signed-off-by: Wei Li <liwei391@...wei.com>
> > Signed-off-by: Sumit Garg <sumit.garg@...aro.org>
> > Tested-by: Douglas Anderson <dianders@...omium.org>
> > ---
> >  arch/arm64/include/asm/debug-monitors.h | 1 +
> >  arch/arm64/kernel/debug-monitors.c      | 5 +++++
> >  arch/arm64/kernel/kgdb.c                | 2 ++
> >  3 files changed, 8 insertions(+)
> >
> > diff --git a/arch/arm64/include/asm/debug-monitors.h b/arch/arm64/include/asm/debug-monitors.h
> > index 7b7e05c02691..ce3875ad5cd3 100644
> > --- a/arch/arm64/include/asm/debug-monitors.h
> > +++ b/arch/arm64/include/asm/debug-monitors.h
> > @@ -104,6 +104,7 @@ void user_regs_reset_single_step(struct user_pt_regs *regs,
> >  void kernel_enable_single_step(struct pt_regs *regs);
> >  void kernel_disable_single_step(void);
> >  int kernel_active_single_step(void);
> > +void kernel_regs_reset_single_step(struct pt_regs *regs);
> >
> >  #ifdef CONFIG_HAVE_HW_BREAKPOINT
> >  int reinstall_suspended_bps(struct pt_regs *regs);
> > diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
> > index 3da09778267e..9af898b22ed4 100644
> > --- a/arch/arm64/kernel/debug-monitors.c
> > +++ b/arch/arm64/kernel/debug-monitors.c
> > @@ -438,6 +438,11 @@ int kernel_active_single_step(void)
> >  }
> >  NOKPROBE_SYMBOL(kernel_active_single_step);
> >
> > +void kernel_regs_reset_single_step(struct pt_regs *regs)
> > +{
> > +     set_regs_spsr_ss(regs);
> > +}
>
> Just a nit on the naming here, but please can this be
> kernel_rewind_single_step() instead? I think it's closer to the rewind
> function we have for user tasks than the reset function.
>

Sure, I will do the renaming in the next version.

-Sumit

> Cheers,
>
> Will