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]
Message-ID: <CAK9=C2X2J4ROJ7nKB0hcD9dVav7ZMFWw2Qy+GEsmYN_Tt8DxPQ@mail.gmail.com>
Date: Mon, 11 Aug 2025 15:11:27 +0530
From: Anup Patel <apatel@...tanamicro.com>
To: Jesse Taube <jesse@...osinc.com>
Cc: linux-riscv@...ts.infradead.org, Paul Walmsley <paul.walmsley@...ive.com>, 
	Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>, 
	Alexandre Ghiti <alex@...ti.fr>, Oleg Nesterov <oleg@...hat.com>, Kees Cook <kees@...nel.org>, 
	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, 
	Arnaldo Carvalho de Melo <acme@...nel.org>, Namhyung Kim <namhyung@...nel.org>, 
	Mark Rutland <mark.rutland@....com>, 
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Jiri Olsa <jolsa@...nel.org>, 
	Ian Rogers <irogers@...gle.com>, Adrian Hunter <adrian.hunter@...el.com>, 
	"Liang, Kan" <kan.liang@...ux.intel.com>, Shuah Khan <shuah@...nel.org>, 
	Himanshu Chauhan <hchauhan@...tanamicro.com>, Charlie Jenkins <charlie@...osinc.com>, 
	Samuel Holland <samuel.holland@...ive.com>, Conor Dooley <conor.dooley@...rochip.com>, 
	Deepak Gupta <debug@...osinc.com>, Andrew Jones <ajones@...tanamicro.com>, 
	Atish Patra <atishp@...osinc.com>, Mayuresh Chitale <mchitale@...tanamicro.com>, 
	Evan Green <evan@...osinc.com>, WangYuli <wangyuli@...ontech.com>, 
	Huacai Chen <chenhuacai@...nel.org>, Arnd Bergmann <arnd@...db.de>, 
	Andrew Morton <akpm@...ux-foundation.org>, Luis Chamberlain <mcgrof@...nel.org>, 
	"Mike Rapoport (Microsoft)" <rppt@...nel.org>, Nam Cao <namcao@...utronix.de>, 
	Yunhui Cui <cuiyunhui@...edance.com>, Joel Granados <joel.granados@...nel.org>, 
	Clément Léger <cleger@...osinc.com>, 
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>, Celeste Liu <coelacanthushex@...il.com>, 
	Chunyan Zhang <zhangchunyan@...as.ac.cn>, Nylon Chen <nylon.chen@...ive.com>, 
	Thomas Gleixner <tglx@...utronix.de>, Thomas Weißschuh <thomas.weissschuh@...utronix.de>, 
	Vincenzo Frascino <vincenzo.frascino@....com>, Joey Gouly <joey.gouly@....com>, 
	Akihiko Odaki <akihiko.odaki@...nix.com>, Ravi Bangoria <ravi.bangoria@....com>, 
	linux-kernel@...r.kernel.org, linux-mm@...ck.org, 
	linux-perf-users@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH 5/8] riscv: hw_breakpoint: Use icount for single stepping

Hi Jesse,

On Wed, Aug 6, 2025 at 1:10 AM Jesse Taube <jesse@...osinc.com> wrote:
>
> The Sdtrig RISC-V ISA extension does not have a resume flag for
> returning to and executing the instruction at the breakpoint.
> To avoid skipping the instruction or looping, it is necessary to remove
> the hardware breakpoint and single step. Use the icount feature of
> Sdtrig to accomplish this. Use icount as default with an option to allow
> software-based single stepping when hardware or SBI does not have
> icount functionality, as it may cause unwanted side effects when reading
> the instruction from memory.
>
> Signed-off-by: Jesse Taube <jesse@...osinc.com>
> ---
> OpenSBI implementation of sbi_debug_read_triggers does not return the
> updated CSR values. There needs to be a check for working
> sbi_debug_read_triggers before this works.
>
> https://lists.riscv.org/g/tech-prs/message/1476
>
> RFC -> V1:
>  - Add dbtr_mode to rv_init_icount_trigger
>  - Add icount_triggered to check which breakpoint was triggered
>  - Fix typo: s/affects/effects
>  - Move HW_BREAKPOINT_COMPUTE_STEP to Platform type
> ---
>  arch/riscv/Kconfig                |  11 ++
>  arch/riscv/kernel/hw_breakpoint.c | 179 +++++++++++++++++++++++++++---
>  2 files changed, 172 insertions(+), 18 deletions(-)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index fd8b62cdc6f5..37f01ed199f3 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -546,6 +546,17 @@ config RISCV_COMBO_SPINLOCKS
>
>  endchoice
>
> +config HW_BREAKPOINT_COMPUTE_STEP
> +       bool "Allow computing hardware breakpoint step address"
> +       default n
> +       depends on HAVE_HW_BREAKPOINT
> +       help
> +         Select this option if hardware breakpoints are desired, but
> +         hardware or SBI does not have icount functionality. This may cause
> +         unwanted side effects when reading the instruction from memory.
> +
> +         If unsure, say N.
> +

We expect the same kernel image to work on a platform with
icount triggers and without icount triggers.

Please drop this kconfig option. The decision of falling back to
computing hardware breakpoint step address should be at
boot-time and not compile-time.

Regards,
Anup

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ