Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: Vladimir Murzin <vladimir.murzin@arm.com>
To: linux-kselftest@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org, shuah@kernel.org,
	broonie@kernel.org, usama.anjum@arm.com, mark.rutland@arm.com,
	will@kernel.org, catalin.marinas@arm.com
Subject: [PATCH 1/2] kselftest/arm64/mte: Introduce MTE safe memory accessors
Date: Tue, 22 Sep 2026 11:59:58 +0100	[thread overview]
Message-ID: <20260922105959.129380-2-vladimir.murzin@arm.com> (raw)
In-Reply-To: <20260922105959.129380-1-vladimir.murzin@arm.com>

The MTE selftests assume that they can skip (expected) MTE faults by
advancing the PC by 4 in mte_default_handler(), but this is not
generally safe, as the faults are triggered from arbitrary library
functions (e.g. memset() and memcpy()). For instance, memset() could
be implemented as simple as:

  mov	x3, x0       // copy pointer
  add	x4, x0, x2   // calculate end
loop:
  strb	w1, [x3], #1 // faulting access
  cmp	x3, x4
  b.ne	loop
  ret

which leads to an infinite loop since X3 could not be updated.

Or, it could be having advanced implementation (FEAT_MOPS):

  mov	x3, x0         // copy pointer
  setp	[x3]!, x2!, x1 // prologue
  setm	[x3]!, x2!, x1 // main
  sete	[x3]!, x2!, x1 // epilogue
  ret

with faulting access at prologue advancing PC to main could lead to
infinite loop due to main could be triggering unaligned access fault
which kernel fixing up by advancing PC back to prologue.

Instead of relying on arbitrary implementations of library functions
introduce helpers to perform the faulting accesses, where those faults
can safely be handled.

Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
 .../selftests/arm64/mte/mte_common_util.h     |  4 ++
 .../testing/selftests/arm64/mte/mte_helper.S  | 44 +++++++++++++++++++
 2 files changed, 48 insertions(+)

diff --git a/tools/testing/selftests/arm64/mte/mte_common_util.h b/tools/testing/selftests/arm64/mte/mte_common_util.h
index 250d671329a5..547ec5659f78 100644
--- a/tools/testing/selftests/arm64/mte/mte_common_util.h
+++ b/tools/testing/selftests/arm64/mte/mte_common_util.h
@@ -64,6 +64,10 @@ void mte_restore_setup(void);
 int mte_switch_mode(int mte_option, unsigned long incl_mask, bool stonly);
 void mte_initialize_current_context(int mode, uintptr_t ptr, ssize_t range);
 
+/* Safe memory access functions */
+void *memset_safe(void *s, int c, size_t n);
+void *memcpy_safe(void *dest, const void *src, size_t n);
+
 /* Common utility functions */
 int create_temp_file(void);
 
diff --git a/tools/testing/selftests/arm64/mte/mte_helper.S b/tools/testing/selftests/arm64/mte/mte_helper.S
index a55dbbc56ed1..eb62abfa1eb4 100644
--- a/tools/testing/selftests/arm64/mte/mte_helper.S
+++ b/tools/testing/selftests/arm64/mte/mte_helper.S
@@ -128,3 +128,47 @@ ENTRY(mte_get_pstate_tco)
 	ubfx	x0, x0, #MT_PSTATE_TCO_SHIFT, #1
 	ret
 ENDPROC(mte_get_pstate_tco)
+
+/*
+ * memset_safe: Fill memory with a constant byte
+ * Input:
+ *		x0 - destination pointer
+ *		x1 - constant byte
+ *		x2 - number of bytes to fill
+ * Return:
+ *		x0 - original destination pointer
+ */
+ENTRY(memset_safe)
+	cbz	x2, 2f
+	add	x4, x2, x0
+	mov	x3, x0
+1:
+	strb	w1, [x3]
+	add	x3, x3, #0x1
+	cmp	x3, x4
+	b.ne	1b
+2:
+	ret
+ENDPROC(memset_safe)
+
+/*
+ * memcpy_safe: Copy memory area
+ * Input:
+ *		x0 - destination pointer
+ *		x1 - source pointer
+ *		x2 - number of bytes to copy
+ * Return:
+ *		x0 - destination pointer
+ */
+ENTRY(memcpy_safe)
+	cbz	x2, 2f
+	mov	x3, #0x0
+1:
+	ldrb	w4, [x1, x3]
+	strb	w4, [x0, x3]
+	add	x3, x3, #0x1
+	cmp	x3, x2
+	b.ne	1b
+2:
+	ret
+ENDPROC(memcpy_safe)
-- 
2.34.1


  reply	other threads:[~2026-09-22 11:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-22 10:59 [PATCH 0/2] kselftest: Make MTE memory access robust Vladimir Murzin
2026-09-22 10:59 ` Vladimir Murzin [this message]
2026-09-22 10:59 ` [PATCH 2/2] kselftest/arm64/mte: Use MTE safe memory accessors Vladimir Murzin
2026-09-22 17:10 ` [PATCH 0/2] kselftest: Make MTE memory access robust Muhammad Usama Anjum
2026-10-06 22:56 ` Catalin Marinas

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=20260922105959.129380-2-vladimir.murzin@arm.com \
    --to=vladimir.murzin@arm.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=shuah@kernel.org \
    --cc=usama.anjum@arm.com \
    --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