public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Khaja Hussain Shaik Khaji <khaja.khaji@oss.qualcomm.com>
Cc: linux-arm-kernel@lists.infradead.org, kprobes@vger.kernel.org,
	linux-kernel@vger.kernel.org, will@kernel.org,
	catalin.marinas@arm.com, masami.hiramatsu@linaro.org
Subject: Re: [PATCH] arm64: insn: Route BTI to simulate_nop to avoid XOL/SS at function entry
Date: Tue, 11 Nov 2025 10:26:44 +0000	[thread overview]
Message-ID: <aRMPZB6W04_l7iSB@J2N7QTR9R3> (raw)
In-Reply-To: <20251106104955.2089268-1-khaja.khaji@oss.qualcomm.com>

On Thu, Nov 06, 2025 at 04:19:55PM +0530, Khaja Hussain Shaik Khaji wrote:
> On arm64 with branch protection, functions typically begin with a BTI
> (Branch Target Identification) landing pad. Today the decoder treats BTI
> as requiring out-of-line single-step (XOL), allocating a slot and placing
> an SS-BRK. Under SMP this leaves a small window before DAIF is masked
> where an asynchronous exception or nested probe can interleave and clear
> current_kprobe, resulting in an SS-BRK panic.

If you can take an exception here, and current_kprobe gets cleared, then
XOL stepping is broken in general, but just for BTI.

> Handle BTI like NOP in the decoder and simulate it (advance PC by one
> instruction). This avoids XOL/SS-BRK at these sites and removes the
> single-step window, while preserving correctness for kprobes since BTI’s
> branch-target enforcement has no program-visible effect in this EL1
> exception context.

One of the reasons for doing this out-of-line is that we should be able
to mark the XOL slot as a guarded page, and get the correct BTI
behaviour. It looks like we don't currently do that, which is a bug.

Just skipping the BTI isn't right; that throws away the BTI target
check.

> In practice BTI is most commonly observed at function entry, so the main
> effect of this change is to eliminate entry-site single-stepping. Other
> instructions and non-entry sites are unaffected.
> 
> Signed-off-by: Khaja Hussain Shaik Khaji <khaja.khaji@oss.qualcomm.com>
> ---
>  arch/arm64/include/asm/insn.h            | 5 -----
>  arch/arm64/kernel/probes/decode-insn.c   | 9 ++++++---
>  arch/arm64/kernel/probes/simulate-insn.c | 1 +
>  3 files changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
> index 18c7811774d3..7e80cc1f0c3d 100644
> --- a/arch/arm64/include/asm/insn.h
> +++ b/arch/arm64/include/asm/insn.h
> @@ -452,11 +452,6 @@ static __always_inline bool aarch64_insn_is_steppable_hint(u32 insn)
>  	case AARCH64_INSN_HINT_PACIASP:
>  	case AARCH64_INSN_HINT_PACIBZ:
>  	case AARCH64_INSN_HINT_PACIBSP:
> -	case AARCH64_INSN_HINT_BTI:
> -	case AARCH64_INSN_HINT_BTIC:
> -	case AARCH64_INSN_HINT_BTIJ:
> -	case AARCH64_INSN_HINT_BTIJC:
> -	case AARCH64_INSN_HINT_NOP:
>  		return true;
>  	default:
>  		return false;
> diff --git a/arch/arm64/kernel/probes/decode-insn.c b/arch/arm64/kernel/probes/decode-insn.c
> index 6438bf62e753..7ce2cf5e21d3 100644
> --- a/arch/arm64/kernel/probes/decode-insn.c
> +++ b/arch/arm64/kernel/probes/decode-insn.c
> @@ -79,10 +79,13 @@ enum probe_insn __kprobes
>  arm_probe_decode_insn(u32 insn, struct arch_probe_insn *api)
>  {
>  	/*
> -	 * While 'nop' instruction can execute in the out-of-line slot,
> -	 * simulating them in breakpoint handling offers better performance.
> +	 * NOP and BTI (Branch Target Identification) have no program‑visible side
> +	 * effects for kprobes purposes. Simulate them to avoid XOL/SS‑BRK and the
> +	 * small single‑step window. BTI’s branch‑target enforcement semantics are
> +	 * irrelevant in this EL1 kprobe context, so advancing PC by one insn is
> +	 * sufficient here.
>  	 */
> -	if (aarch64_insn_is_nop(insn)) {
> +	if (aarch64_insn_is_nop(insn) || aarch64_insn_is_bti(insn)) {
>  		api->handler = simulate_nop;
>  		return INSN_GOOD_NO_SLOT;
>  	}

I'm not necessarily opposed to emulating the BTI, but:

(a) The BTI should not be emulated as a NOP. I am not keen on simulating
    the BTI exception in software, and would strongly prefer that's
    handled by HW (e.g. in the XOL slot).

(b) As above, it sounds like this is bodging around a more general
    problem. We must solve that more general problem.

> diff --git a/arch/arm64/kernel/probes/simulate-insn.c b/arch/arm64/kernel/probes/simulate-insn.c
> index 4c6d2d712fbd..b83312cb70ba 100644
> --- a/arch/arm64/kernel/probes/simulate-insn.c
> +++ b/arch/arm64/kernel/probes/simulate-insn.c
> @@ -200,5 +200,6 @@ simulate_ldrsw_literal(u32 opcode, long addr, struct pt_regs *regs)
>  void __kprobes
>  simulate_nop(u32 opcode, long addr, struct pt_regs *regs)
>  {
> +	/* Also used as BTI simulator: both just advance PC by one insn. */
>  	arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE);
>  }

This comment should go.

Mark.


  reply	other threads:[~2025-11-11 10:27 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-06 10:49 [PATCH] arm64: insn: Route BTI to simulate_nop to avoid XOL/SS at function entry Khaja Hussain Shaik Khaji
2025-11-11 10:26 ` Mark Rutland [this message]
2025-11-12 12:17   ` Mark Rutland
2026-02-17 13:38 ` [PATCH v2 0/2] arm64: kprobes: fix XOL preemption window Khaja Hussain Shaik Khaji
2026-02-17 13:38   ` [PATCH v2 1/2] arm64: kprobes: disable preemption across XOL single-step Khaja Hussain Shaik Khaji
2026-02-17 16:55     ` Mark Rutland
2026-02-23 16:07       ` Masami Hiramatsu
2026-03-02 10:19       ` Khaja Hussain Shaik Khaji
2026-03-02 10:23         ` Mark Rutland
2026-03-02 10:53       ` [PATCH v3 0/1] kernel: kprobes: fix cur_kprobe corruption during Khaja Hussain Shaik Khaji
2026-03-02 10:53         ` [PATCH v3 1/1] kernel: kprobes: fix cur_kprobe corruption during re-entrant kprobe_busy_begin() calls Khaja Hussain Shaik Khaji
2026-03-02 13:38           ` Mark Rutland
2026-03-02 11:23         ` [PATCH v3 0/1] kernel: kprobes: fix cur_kprobe corruption during Mark Rutland
2026-03-02 12:23           ` [PATCH v3 0/1] kernel: kprobes: fix cur_kprobe corruption during re-entrant kprobe_busy_begin() calls Khaja Hussain Shaik Khaji
2026-03-02 13:43             ` Mark Rutland
2026-02-17 13:38   ` [PATCH v2 2/2] arm64: insn: drop NOP from steppable hint list Khaja Hussain Shaik Khaji
2026-02-17 16:57     ` Mark Rutland
2026-02-24  8:23       ` Masami Hiramatsu

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=aRMPZB6W04_l7iSB@J2N7QTR9R3 \
    --to=mark.rutland@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=khaja.khaji@oss.qualcomm.com \
    --cc=kprobes@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu@linaro.org \
    --cc=will@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox