All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: Ada Couprie Diaz <ada.coupriediaz@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	"Luis Claudio R. Goncalves" <lgoncalv@redhat.com>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: Re: [PATCH v2 07/11] arm64: debug: split single stepping exception entry
Date: Tue, 20 May 2025 17:29:14 +0100	[thread overview]
Message-ID: <20250520162913.GA19155@willie-the-truck> (raw)
In-Reply-To: <20250512174326.133905-8-ada.coupriediaz@arm.com>

On Mon, May 12, 2025 at 06:43:22PM +0100, Ada Couprie Diaz wrote:
> Currently all debug exceptions share common entry code and are routed
> to `do_debug_exception()`, which calls dynamically-registered
> handlers for each specific debug exception. This is unfortunate as
> different debug exceptions have different entry handling requirements,
> and it would be better to handle these distinct requirements earlier.
> 
> The single stepping exception has the most constraints : it can be
> exploited to train branch predictors and it needs special handling at EL1
> for the Cortex-A76 erratum #1463225. We need to conserve all those
> mitigations.
> Move the call to `arm64_apply_bp_hardening()` to `entry-common.c` as
> it is needed for exceptions coming from EL0 only.
> However, it does not write an address at FAR_EL1, as only hardware
> watchpoints do so.
> 
> The single-step handler does its own signaling if it needs to and only
> returns 0, so we can call it directly from `entry-common.c`.
> 
> Split the single stepping exception entry, adjust the function signature,
> keep the security mitigation and erratum handling.
> 
> When taking a soft-step exception from EL0, most of the single stepping
> handling is safely preemptible : the only possible handler is
> `uprobe_singlestep_handler()`. It only operates on task-local data and
> properly checks its validity, then raises a Thread Information Flag,
> processed before returning to userspace in `do_notify_resume()`, which
> is already preemptible.
> However, the soft-step handler first calls `reinstall_suspended_bps()`
> to check if there is any hardware breakpoint or watchpoint pending
> or already stepped through.
> This cannot be preempted as it manipulates the hardware breakpoint and
> watchpoint registers.
> 
> Move the call to `reinstall_suspended_bps()` to `entry-common.c` and
> adjust the relevant comments.
> We can now safely unmask interrupts before handling the step itself,
> fixing a PREEMPT_RT issue where the handler could call a sleeping function
> with preemption disabled.
> 
> Signed-off-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
> Closes: https://lore.kernel.org/linux-arm-kernel/Z6YW_Kx4S2tmj2BP@uudg.org/
> ---
>  arch/arm64/include/asm/exception.h |  1 +
>  arch/arm64/kernel/debug-monitors.c | 19 +++----------
>  arch/arm64/kernel/entry-common.c   | 43 ++++++++++++++++++++++++++++++
>  arch/arm64/kernel/hw_breakpoint.c  |  6 ++---
>  4 files changed, 51 insertions(+), 18 deletions(-)

[...]

> @@ -770,6 +790,25 @@ static void noinstr el0_breakpt(struct pt_regs *regs, unsigned long esr)
>  	exit_to_user_mode(regs);
>  }
>  
> +static void noinstr el0_softstp(struct pt_regs *regs, unsigned long esr)
> +{
> +	if (!is_ttbr0_addr(regs->pc))
> +		arm64_apply_bp_hardening();

Similar to the other patch, I think this is a functional change. It
might be fine, but it should be called out in the commit message if it's
intentional.

> +	enter_from_user_mode(regs);
> +	/*
> +	 * After handling a breakpoint, we suspend the breakpoint
> +	 * and use single-step to move to the next instruction.
> +	 * If we have a suspended breakpoint there's nothing more to do:
> +	 * complete the single-step.
> +	 */
> +	if (reinstall_suspended_bps(regs)) {
> +		local_daif_restore(DAIF_PROCCTX);
> +		do_softstep(esr, regs);
> +	}
> +	exit_to_user_mode(regs);

I quite like the look of this now, but perhaps we could rename
reinstall_suspended_bps() and change the return value to make things a
bit more readable? For example, 'if (!stepped_suspended_breakpt(regs))'
or something like that? What do you think?

Will


  reply	other threads:[~2025-05-20 16:45 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-12 17:43 [PATCH v2 00/11] arm64: debug: remove hook registration, split exception entry Ada Couprie Diaz
2025-05-12 17:43 ` [PATCH v2 01/11] arm64: debug: clean up single_step_handler logic Ada Couprie Diaz
2025-05-20 15:35   ` Will Deacon
2025-05-12 17:43 ` [PATCH v2 02/11] arm64: debug: call software break handlers statically Ada Couprie Diaz
2025-05-20 15:35   ` Will Deacon
2025-06-02 16:39     ` Ada Couprie Diaz
2025-05-12 17:43 ` [PATCH v2 03/11] arm64: debug: call step " Ada Couprie Diaz
2025-05-20 15:35   ` Will Deacon
2025-05-28 16:02     ` Ada Couprie Diaz
2025-05-12 17:43 ` [PATCH v2 04/11] arm64: debug: remove break/step handler registration infrastructure Ada Couprie Diaz
2025-05-20 15:36   ` Will Deacon
2025-05-12 17:43 ` [PATCH v2 05/11] arm64: entry: Add entry and exit functions for debug exceptions Ada Couprie Diaz
2025-05-20 15:36   ` Will Deacon
2025-05-28 14:08     ` Ada Couprie Diaz
2025-05-29 10:11       ` Will Deacon
2025-05-12 17:43 ` [PATCH v2 06/11] arm64: debug: split hardware breakpoint exeception entry Ada Couprie Diaz
2025-05-20 15:36   ` Will Deacon
2025-05-28 15:17     ` Mark Rutland
2025-05-28 16:10       ` Ada Couprie Diaz
2025-05-12 17:43 ` [PATCH v2 07/11] arm64: debug: split single stepping exception entry Ada Couprie Diaz
2025-05-20 16:29   ` Will Deacon [this message]
2025-05-28 15:22     ` Mark Rutland
2025-05-29 10:10       ` Will Deacon
2025-05-29 10:48         ` Ada Couprie Diaz
2025-05-12 17:43 ` [PATCH v2 08/11] arm64: debug: split hardware watchpoint " Ada Couprie Diaz
2025-05-20 16:59   ` Will Deacon
2025-05-28 13:47     ` Ada Couprie Diaz
2025-05-28 15:42       ` Mark Rutland
2025-05-29 10:13         ` Will Deacon
2025-05-12 17:43 ` [PATCH v2 09/11] arm64: debug: split brk64 " Ada Couprie Diaz
2025-05-12 17:43 ` [PATCH v2 10/11] arm64: debug: split bkpt32 " Ada Couprie Diaz
2025-05-21  9:07   ` Will Deacon
2025-05-29 10:43     ` Ada Couprie Diaz
2025-05-12 17:43 ` [PATCH v2 11/11] arm64: debug: remove debug exception registration infrastructure Ada Couprie Diaz
2025-05-21  9:38   ` Will Deacon
2025-05-28 16:41     ` Ada Couprie Diaz
2025-05-29 10:15       ` Will Deacon
2025-05-13 12:25 ` [PATCH v2 00/11] arm64: debug: remove hook registration, split exception entry Luis Claudio R. Goncalves
2025-05-13 15:19   ` Ada Couprie Diaz
2025-05-16 11:57     ` Luis Claudio R. Goncalves
2025-05-28 10:38       ` Ada Couprie Diaz
2025-06-03 16:10         ` Ada Couprie Diaz

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=20250520162913.GA19155@willie-the-truck \
    --to=will@kernel.org \
    --cc=ada.coupriediaz@arm.com \
    --cc=bigeasy@linutronix.de \
    --cc=catalin.marinas@arm.com \
    --cc=lgoncalv@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.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.