Skip to contentSkip to conversation

kasan: add hardware tag-based mode for arm64

PATCH Superseded Andrey Konovalov 6 participants 101 messages Aug 14, 2020 – Sep 18, 2020

Subsystems (16)

v1 of 11 Superseded Latest is v11 →

lore
Share & tools
lore
#0 lore raw

cover kasan: add hardware tag-based mode for arm64

This patchset adds a new hardware tag-based mode to KASAN [1]. The new mode is similar to the existing software tag-based KASAN, but relies on arm64 Memory Tagging Extension (MTE) [2] to perform memory and pointer tagging (instead of shadow memory and compiler instrumentation).

This patchset is available here:

https://github.com/xairy/linux/tree/up-kasan-mte-v1

and has also been uploaded to the Linux kernel Gerrit instance:

https://linux-review.googlesource.com/c/linux/kernel/git/torvalds/linux/+/2700

This patchset is based on the v7 of the user MTE patches [3], along with some KASAN patches cherry-picked from the current mainline.

This patchset consists of three parts:

1. Rework KASAN code to allow easier integration of the hardware tag-based mode.
2. Introduce core in-kernel MTE routines.
3. Combine the two parts together and introduce the new mode.

For testing in QEMU hardware tag-based KASAN requires:

1. QEMU built from master [4] with these patches [5] on top.
2. GCC version 10.

[1] https://www.kernel.org/doc/html/latest/dev-tools/kasan.html
[2] https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/enhancing-memory-safety
[3] git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux for-next/mte
[4] https://github.com/qemu/qemu
[5] https://lists.gnu.org/archive/html/qemu-devel/2020-08/msg02677.html

====== Overview

The underlying ideas of the approach used by hardware tag-based KASAN are:

1. By relying on the Top Byte Ignore (TBI) arm64 CPU feature, pointer tags are stored in the top byte of each kernel pointer.

2. With the Memory Tagging Extension (MTE) arm64 CPU feature, memory tags for kernel memory allocations are stored in a dedicated memory not accessible via normal instuctions.

3. On each memory allocation, a random tag is generated, embedded it into the returned pointer, and the corresponding memory is tagged with the same tag value.

4. With MTE the CPU performs a check on each memory access to make sure that the pointer tag matches the memory tag.

5. On a tag mismatch the CPU generates a tag fault, and a KASAN report is printed.

Same as other KASAN modes, hardware tag-based KASAN is intended as a debugging feature at this point.

====== Rationale

There are two main reasons for this new hardware tag-based mode:

1. Previously implemented software tag-based KASAN is being successfully used on dogfood testing devices due to its low memory overhead (as initially planned). The new hardware mode keeps the same low memory overhead, and is expected to have significantly lower performance impact, due to the tag checks being performed by the hardware. Therefore the new mode can be used as a better alternative in dogfood testing for hardware that supports MTE.

2. The new mode lays the groundwork for the planned in-kernel MTE-based memory corruption mitigation to be used in production.

====== Technical details

From the implementation perspective, hardware tag-based KASAN is almost identical to the software mode. The key difference is using MTE for assigning and checking tags.

Compared to the software mode, the hardware mode uses 4 bits per tag, as dictated by MTE. Pointer tags are stored in bits [56:60), the top 4 bits have the normal value 0xF. Having less distict tags increases the probablity of false negatives (from ~1/256 to ~1/16) in certain cases.

Only synchronous exceptions are set up and used by hardware tag-based KASAN.

====== Benchmarks

Note: all measurements have been performed with software emulation of Memory Tagging Extension, performance numbers for hardware tag-based KASAN on the actual hardware are expected to be better.

Boot time [1]:
* 2.8 sec for clean kernel
* 5.7 sec for hardware tag-based KASAN
* 11.8 sec for software tag-based KASAN
* 11.6 sec for generic KASAN

Slab memory usage after boot [2]:
* 7.0 kb for clean kernel
* 9.7 kb for hardware tag-based KASAN
* 9.7 kb for software tag-based KASAN
* 41.3 kb for generic KASAN

Measurements have been performed with:
* defconfig-based configs
* Manually built QEMU master with these patches on top [3]
* QEMU arguments: -machine virt,mte=on -cpu max
* CONFIG_KASAN_STACK_ENABLE disabled
* CONFIG_KASAN_INLINE enabled
* clang-10 as the compiler and gcc-10 as the assembler

[1] Time before the ext4 driver is initialized.
[2] Measured as cat /proc/meminfo | grep Slab.
[3] https://lists.gnu.org/archive/html/qemu-devel/2020-08/msg02677.html

====== Notes

The cover letter for software tag-based KASAN patchset can be found here:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0116523cfffa62aeb5aa3b85ce7419f3dae0c1b8

Andrey Konovalov (29):
kasan: KASAN_VMALLOC depends on KASAN_GENERIC
kasan: group vmalloc code
kasan: shadow declarations only for software modes
kasan: rename (un)poison_shadow to (un)poison_memory
kasan: rename KASAN_SHADOW_* to KASAN_GRANULE_*
kasan: only build init.c for software modes
kasan: split out shadow.c from common.c
kasan: rename generic/tags_report.c files
kasan: don't duplicate config dependencies
kasan: hide invalid free check implementation
kasan: decode stack frame only with KASAN_STACK_ENABLE kasan, arm64: only init shadow for software modes kasan, arm64: only use kasan_depth for software modes
kasan: rename addr_has_shadow to addr_has_metadata
kasan: rename print_shadow_for_address to print_memory_metadata
kasan: kasan_non_canonical_hook only for software modes
kasan: rename SHADOW layout macros to META
kasan: separate metadata_fetch_row for each mode
kasan: don't allow SW_TAGS with ARM64_MTE
kasan: introduce CONFIG_KASAN_HW_TAGS
kasan, arm64: align allocations for HW_TAGS
kasan: define KASAN_GRANULE_SIZE for HW_TAGS
kasan, x86, s390: update undef CONFIG_KASAN
kasan, arm64: expand CONFIG_KASAN checks
kasan, arm64: implement HW_TAGS runtime
kasan, arm64: print report from tag fault handler kasan, slub: reset tags when accessing metadata kasan, arm64: enable CONFIG_KASAN_HW_TAGS
kasan: add documentation for hardware tag-based mode

Vincenzo Frascino (6):
arm64: mte: Add in-kernel MTE helpers
arm64: mte: Add in-kernel tag fault handler
arm64: mte: Enable in-kernel MTE
arm64: mte: Convert gcr_user into an exclude mask
arm64: mte: Switch GCR_EL1 in kernel entry and exit kasan, arm64: Enable TBI EL1

 Documentation/dev-tools/kasan.rst         |  75 ++-
 arch/arm64/Kconfig                        |   3 +-
 arch/arm64/Makefile                       |   2 +-
 arch/arm64/include/asm/assembler.h        |   2 +-
 arch/arm64/include/asm/cache.h            |   3 +
 arch/arm64/include/asm/esr.h              |   1 +
 arch/arm64/include/asm/kasan.h            |   8 +-
 arch/arm64/include/asm/memory.h           |   6 +-
 arch/arm64/include/asm/mte.h              |  54 ++-
 arch/arm64/include/asm/mte_asm.h          |  10 +
 arch/arm64/include/asm/processor.h        |   2 +-
 arch/arm64/include/asm/string.h           |   5 +-
 arch/arm64/kernel/asm-offsets.c           |   3 +
 arch/arm64/kernel/cpufeature.c            |  11 +-
 arch/arm64/kernel/entry.S                 |  28 ++
 arch/arm64/kernel/head.S                  |   2 +-
 arch/arm64/kernel/image-vars.h            |   2 +-
 arch/arm64/kernel/mte.c                   |  87 +++-
 arch/arm64/kernel/setup.c                 |   1 -
 arch/arm64/lib/mte.S                      |  41 ++
 arch/arm64/mm/dump.c                      |   6 +-
 arch/arm64/mm/fault.c                     |  59 ++-
 arch/arm64/mm/kasan_init.c                |  22 +-
 arch/arm64/mm/proc.S                      |   2 +-
 arch/s390/boot/string.c                   |   1 +
 arch/x86/boot/compressed/misc.h           |   1 +
 include/linux/kasan-checks.h              |   2 +-
 include/linux/kasan.h                     | 110 +++--
 include/linux/mm.h                        |   2 +-
 include/linux/moduleloader.h              |   3 +-
 include/linux/page-flags-layout.h         |   2 +-
 include/linux/sched.h                     |   2 +-
 include/linux/string.h                    |   2 +-
 init/init_task.c                          |   2 +-
 kernel/fork.c                             |   4 +-
 lib/Kconfig.kasan                         |  60 ++-
 lib/test_kasan.c                          |   2 +-
 mm/kasan/Makefile                         |  21 +-
 mm/kasan/common.c                         | 554 ++--------------------
 mm/kasan/generic.c                        |  33 +-
 mm/kasan/generic_report.c                 | 165 -------
 mm/kasan/init.c                           |  10 +-
 mm/kasan/kasan.h                          |  45 +-
 mm/kasan/mte.c                            |  76 +++
 mm/kasan/report.c                         | 254 ++--------
 mm/kasan/report_generic.c                 | 331 +++++++++++++
 mm/kasan/report_mte.c                     |  47 ++
 mm/kasan/{tags_report.c => report_tags.c} |   7 +-
 mm/kasan/shadow.c                         | 509 ++++++++++++++++++++
 mm/kasan/tags.c                           |  14 +-
 mm/page_poison.c                          |   2 +-
 mm/ptdump.c                               |  13 +-
 mm/slab_common.c                          |   2 +-
 mm/slub.c                                 |  25 +-
 scripts/Makefile.lib                      |   2 +
 55 files changed, 1653 insertions(+), 1085 deletions(-)
 create mode 100644 arch/arm64/include/asm/mte_asm.h
 delete mode 100644 mm/kasan/generic_report.c
 create mode 100644 mm/kasan/mte.c
 create mode 100644 mm/kasan/report_generic.c
 create mode 100644 mm/kasan/report_mte.c
 rename mm/kasan/{tags_report.c => report_tags.c} (94%)
 create mode 100644 mm/kasan/shadow.c
Signature · 1 line
2.28.0.220.ged08abb693-goog
#1 lore raw

PATCH 1/35 kasan: KASAN_VMALLOC depends on KASAN_GENERIC

Currently only generic KASAN mode supports vmalloc, reflect that in the config.

---
 lib/Kconfig.kasan | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
lib/Kconfig.kasan +1 -1
index 047b53dbfd58..e1d55331b618 100644
@@ -156,7 +156,7 @@ config KASAN_SW_TAGS_IDENTIFY
 
 config KASAN_VMALLOC
 	bool "Back mappings in vmalloc space with real shadow memory"
-	depends on HAVE_ARCH_KASAN_VMALLOC
+	depends on KASAN_GENERIC && HAVE_ARCH_KASAN_VMALLOC
 	help
 	  By default, the shadow region for vmalloc space is the read-only
 	  zero page. This means that KASAN cannot detect errors involving
Signature · 1 line
2.28.0.220.ged08abb693-goog
#2 lore raw

PATCH 2/35 kasan: group vmalloc code

In reply to Andrey Konovalov

This is a preparatory commit for the upcoming addition of a new hardware tag-based (MTE-based) KASAN mode.

Group all vmalloc-related function declarations in include/linux/kasan.h, and their implementations in mm/kasan/common.c.

No functional changes.

---
 include/linux/kasan.h | 41 +++++++++++++----------
 mm/kasan/common.c     | 78 ++++++++++++++++++++++---------------------
 2 files changed, 63 insertions(+), 56 deletions(-)
include/linux/kasan.h +23 -18
index 087fba34b209..bd5b4965a269 100644
@@ -69,19 +69,6 @@ struct kasan_cache {
 	int free_meta_offset;
 };
 
-/*
- * These functions provide a special case to support backing module
- * allocations with real shadow memory. With KASAN vmalloc, the special
- * case is unnecessary, as the work is handled in the generic case.
- */
-#ifndef CONFIG_KASAN_VMALLOC
-int kasan_module_alloc(void *addr, size_t size);
-void kasan_free_shadow(const struct vm_struct *vm);
-#else
-static inline int kasan_module_alloc(void *addr, size_t size) { return 0; }
-static inline void kasan_free_shadow(const struct vm_struct *vm) {}
-#endif
-
 int kasan_add_zero_shadow(void *start, unsigned long size);
 void kasan_remove_zero_shadow(void *start, unsigned long size);
 
@@ -150,9 +137,6 @@ static inline bool kasan_slab_free(struct kmem_cache *s, void *object,
 	return false;
 }
 
-static inline int kasan_module_alloc(void *addr, size_t size) { return 0; }
-static inline void kasan_free_shadow(const struct vm_struct *vm) {}
-
 static inline int kasan_add_zero_shadow(void *start, unsigned long size)
 {
 	return 0;
@@ -205,13 +189,16 @@ static inline void *kasan_reset_tag(const void *addr)
 #endif /* CONFIG_KASAN_SW_TAGS */
 
 #ifdef CONFIG_KASAN_VMALLOC
+
 int kasan_populate_vmalloc(unsigned long addr, unsigned long size);
 void kasan_poison_vmalloc(const void *start, unsigned long size);
 void kasan_unpoison_vmalloc(const void *start, unsigned long size);
 void kasan_release_vmalloc(unsigned long start, unsigned long end,
 			   unsigned long free_region_start,
 			   unsigned long free_region_end);
-#else
+
+#else /* CONFIG_KASAN_VMALLOC */
+
 static inline int kasan_populate_vmalloc(unsigned long start,
 					unsigned long size)
 {
@@ -226,7 +213,25 @@ static inline void kasan_release_vmalloc(unsigned long start,
 					 unsigned long end,
 					 unsigned long free_region_start,
 					 unsigned long free_region_end) {}
-#endif
+
+#endif /* CONFIG_KASAN_VMALLOC */
+
+#if defined(CONFIG_KASAN) && !defined(CONFIG_KASAN_VMALLOC)
+
+/*
+ * These functions provide a special case to support backing module
+ * allocations with real shadow memory. With KASAN vmalloc, the special
+ * case is unnecessary, as the work is handled in the generic case.
+ */
+int kasan_module_alloc(void *addr, size_t size);
+void kasan_free_shadow(const struct vm_struct *vm);
+
+#else /* CONFIG_KASAN && !CONFIG_KASAN_VMALLOC */
+
+static inline int kasan_module_alloc(void *addr, size_t size) { return 0; }
+static inline void kasan_free_shadow(const struct vm_struct *vm) {}
+
+#endif /* CONFIG_KASAN && !CONFIG_KASAN_VMALLOC */
 
 #ifdef CONFIG_KASAN_INLINE
 void kasan_non_canonical_hook(unsigned long addr);
mm/kasan/common.c +40 -38

94 lines not on this page · raw message

Signature · 1 line
2.28.0.220.ged08abb693-goog
#3 lore raw

PATCH 3/35 kasan: shadow declarations only for software modes

In reply to Andrey Konovalov

This is a preparatory commit for the upcoming addition of a new hardware tag-based (MTE-based) KASAN mode.

Group shadow-related KASAN function declarations and only define them for the two existing software modes.

No functional changes for software modes.

---
 include/linux/kasan.h | 44 ++++++++++++++++++++++++++-----------------
 1 file changed, 27 insertions(+), 17 deletions(-)
include/linux/kasan.h +27 -17
index bd5b4965a269..44a9aae44138 100644
@@ -3,16 +3,24 @@
 #define _LINUX_KASAN_H
 
 #include <linux/types.h>
+#include <asm/kasan.h>
 
 struct kmem_cache;
 struct page;
 struct vm_struct;
 struct task_struct;
 
-#ifdef CONFIG_KASAN
+#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 
 #include <linux/pgtable.h>
-#include <asm/kasan.h>
+
+/* Software KASAN implementations use shadow memory. */
+
+#ifdef CONFIG_KASAN_SW_TAGS
+#define KASAN_SHADOW_INIT 0xFF
+#else
+#define KASAN_SHADOW_INIT 0
+#endif
 
 extern unsigned char kasan_early_shadow_page[PAGE_SIZE];
 extern pte_t kasan_early_shadow_pte[PTRS_PER_PTE];
@@ -29,6 +37,23 @@ static inline void *kasan_mem_to_shadow(const void *addr)
 		+ KASAN_SHADOW_OFFSET;
 }
 
+int kasan_add_zero_shadow(void *start, unsigned long size);
+void kasan_remove_zero_shadow(void *start, unsigned long size);
+
+#else /* CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS */
+
+static inline int kasan_add_zero_shadow(void *start, unsigned long size)
+{
+	return 0;
+}
+static inline void kasan_remove_zero_shadow(void *start,
+					unsigned long size)
+{}
+
+#endif /* CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS */
+
+#ifdef CONFIG_KASAN
+
 /* Enable reporting bugs after kasan_disable_current() */
 extern void kasan_enable_current(void);
 
@@ -69,9 +94,6 @@ struct kasan_cache {
 	int free_meta_offset;
 };
 
-int kasan_add_zero_shadow(void *start, unsigned long size);
-void kasan_remove_zero_shadow(void *start, unsigned long size);
-
 size_t __ksize(const void *);
 static inline void kasan_unpoison_slab(const void *ptr)
 {
@@ -137,14 +159,6 @@ static inline bool kasan_slab_free(struct kmem_cache *s, void *object,
 	return false;
 }
 
-static inline int kasan_add_zero_shadow(void *start, unsigned long size)
-{
-	return 0;
-}
-static inline void kasan_remove_zero_shadow(void *start,
-					unsigned long size)
-{}
-
 static inline void kasan_unpoison_slab(const void *ptr) { }
 static inline size_t kasan_metadata_size(struct kmem_cache *cache) { return 0; }
 
@@ -152,8 +166,6 @@ static inline size_t kasan_metadata_size(struct kmem_cache *cache) { return 0; }
 
 #ifdef CONFIG_KASAN_GENERIC
 
-#define KASAN_SHADOW_INIT 0
-
 void kasan_cache_shrink(struct kmem_cache *cache);
 void kasan_cache_shutdown(struct kmem_cache *cache);
 void kasan_record_aux_stack(void *ptr);
@@ -168,8 +180,6 @@ static inline void kasan_record_aux_stack(void *ptr) {}
 
 #ifdef CONFIG_KASAN_SW_TAGS
 
-#define KASAN_SHADOW_INIT 0xFF
-
 void kasan_init_tags(void);
 
 void *kasan_reset_tag(const void *addr);
Signature · 1 line
2.28.0.220.ged08abb693-goog
#4 lore raw

Re: [PATCH 03/35] kasan: shadow declarations only for software modes

Quoted 17 lines · Andrey Konovalov

This is a preparatory commit for the upcoming addition of a new hardware tag-based (MTE-based) KASAN mode.

Group shadow-related KASAN function declarations and only define them for the two existing software modes.

No functional changes for software modes.

---
 include/linux/kasan.h | 44 ++++++++++++++++++++++++++-----------------
 1 file changed, 27 insertions(+), 17 deletions(-)
include/linux/kasan.h +0 -0
index bd5b4965a269..44a9aae44138 100644

[...]

include/linux/kasan.h static inline void *kasan_mem_to_shadow(const void *addr) · line 51

Quoted 7 lines
include/linux/kasan.h +7 -0
+static inline int kasan_add_zero_shadow(void *start, unsigned long size)
+{
+	return 0;
+}
+static inline void kasan_remove_zero_shadow(void *start,
+					unsigned long size)
+{}

Readability suggestion (latest checkpatch.pl allows up to 100 cols):

-static inline void kasan_remove_zero_shadow(void *start,
- unsigned long size)
-{}
+static inline void kasan_remove_zero_shadow(void *start, unsigned long size) {}

Thanks,
-- Marco

#5 lore raw

Re: [PATCH 03/35] kasan: shadow declarations only for software modes

Quoted 30 lines · Marco Elver
Quoted 17 lines · Andrey Konovalov

This is a preparatory commit for the upcoming addition of a new hardware tag-based (MTE-based) KASAN mode.

Group shadow-related KASAN function declarations and only define them for the two existing software modes.

No functional changes for software modes.

---
 include/linux/kasan.h | 44 ++++++++++++++++++++++++++-----------------
 1 file changed, 27 insertions(+), 17 deletions(-)
include/linux/kasan.h +0 -0
index bd5b4965a269..44a9aae44138 100644

[...]

include/linux/kasan.h static inline void *kasan_mem_to_shadow(const void *addr) · line 51

Quoted 7 lines
include/linux/kasan.h +7 -0
+static inline int kasan_add_zero_shadow(void *start, unsigned long size)
+{
+     return 0;
+}
+static inline void kasan_remove_zero_shadow(void *start,
+                                     unsigned long size)
+{}

Readability suggestion (latest checkpatch.pl allows up to 100 cols):

include/linux/kasan.h static inline bool kasan_slab_free(struct kmem_cache *s, void *object,

Quoted 4 lines
include/linux/kasan.h +1 -3
-static inline void kasan_remove_zero_shadow(void *start,
-                                       unsigned long size)
-{}
+static inline void kasan_remove_zero_shadow(void *start, unsigned long size) {}

Will do in v3, thanks!

#6 lore raw

PATCH 4/35 kasan: rename (un)poison_shadow to (un)poison_memory

In reply to Andrey Konovalov

This is a preparatory commit for the upcoming addition of a new hardware tag-based (MTE-based) KASAN mode.

The new mode won't be using shadow memory, but will reuse the same functions. Rename kasan_unpoison_shadow to kasan_unpoison_memory, and kasan_poison_shadow to kasan_poison_memory.

No functional changes.

---
 include/linux/kasan.h |  6 +++---
 kernel/fork.c         |  4 ++--
 mm/kasan/common.c     | 38 +++++++++++++++++++-------------------
 mm/kasan/generic.c    | 12 ++++++------
 mm/kasan/kasan.h      |  2 +-
 mm/kasan/tags.c       |  2 +-
 mm/slab_common.c      |  2 +-
 7 files changed, 33 insertions(+), 33 deletions(-)
include/linux/kasan.h +3 -3
index 44a9aae44138..18617d5c4cd7 100644
@@ -60,7 +60,7 @@ extern void kasan_enable_current(void);
 /* Disable reporting bugs for current task */
 extern void kasan_disable_current(void);
 
-void kasan_unpoison_shadow(const void *address, size_t size);
+void kasan_unpoison_memory(const void *address, size_t size);
 
 void kasan_unpoison_task_stack(struct task_struct *task);
 
@@ -97,7 +97,7 @@ struct kasan_cache {
 size_t __ksize(const void *);
 static inline void kasan_unpoison_slab(const void *ptr)
 {
-	kasan_unpoison_shadow(ptr, __ksize(ptr));
+	kasan_unpoison_memory(ptr, __ksize(ptr));
 }
 size_t kasan_metadata_size(struct kmem_cache *cache);
 
@@ -106,7 +106,7 @@ void kasan_restore_multi_shot(bool enabled);
 
 #else /* CONFIG_KASAN */
 
-static inline void kasan_unpoison_shadow(const void *address, size_t size) {}
+static inline void kasan_unpoison_memory(const void *address, size_t size) {}
 
 static inline void kasan_unpoison_task_stack(struct task_struct *task) {}
 
kernel/fork.c +2 -2
index c9c76a4d1180..c93e93cfbab8 100644
@@ -224,8 +224,8 @@ static unsigned long *alloc_thread_stack_node(struct task_struct *tsk, int node)
 		if (!s)
 			continue;
 
-		/* Clear the KASAN shadow of the stack. */
-		kasan_unpoison_shadow(s->addr, THREAD_SIZE);
+		/* Mark stack accessible for KASAN. */
+		kasan_unpoison_memory(s->addr, THREAD_SIZE);
 
 		/* Clear stale pointers from reused stack. */
 		memset(s->addr, 0, THREAD_SIZE);
mm/kasan/common.c +19 -19
index d1c987f324cd..65933b27df81 100644
@@ -113,7 +113,7 @@ void *memcpy(void *dest, const void *src, size_t len)
  * Poisons the shadow memory for 'size' bytes starting from 'addr'.
  * Memory addresses should be aligned to KASAN_SHADOW_SCALE_SIZE.
  */
-void kasan_poison_shadow(const void *address, size_t size, u8 value)
+void kasan_poison_memory(const void *address, size_t size, u8 value)
 {
 	void *shadow_start, *shadow_end;
 
@@ -130,7 +130,7 @@ void kasan_poison_shadow(const void *address, size_t size, u8 value)
 	__memset(shadow_start, value, shadow_end - shadow_start);
 }
 
-void kasan_unpoison_shadow(const void *address, size_t size)
+void kasan_unpoison_memory(const void *address, size_t size)
 {
 	u8 tag = get_tag(address);
 
@@ -141,7 +141,7 @@ void kasan_unpoison_shadow(const void *address, size_t size)
 	 */
 	address = reset_tag(address);
 
-	kasan_poison_shadow(address, size, tag);
+	kasan_poison_memory(address, size, tag);
 
 	if (size & KASAN_SHADOW_MASK) {
 		u8 *shadow = (u8 *)kasan_mem_to_shadow(address + size);
@@ -158,7 +158,7 @@ static void __kasan_unpoison_stack(struct task_struct *task, const void *sp)
 	void *base = task_stack_page(task);
 	size_t size = sp - base;
 
-	kasan_unpoison_shadow(base, size);
+	kasan_unpoison_memory(base, size);
 }
 
 /* Unpoison the entire stack for a task. */
@@ -177,7 +177,7 @@ asmlinkage void kasan_unpoison_task_stack_below(const void *watermark)
 	 */
 	void *base = (void *)((unsigned long)watermark & ~(THREAD_SIZE - 1));
 
-	kasan_unpoison_shadow(base, watermark - base);
+	kasan_unpoison_memory(base, watermark - base);
 }
 
 void kasan_alloc_pages(struct page *page, unsigned int order)
@@ -191,13 +191,13 @@ void kasan_alloc_pages(struct page *page, unsigned int order)
 	tag = random_tag();
 	for (i = 0; i < (1 << order); i++)
 		page_kasan_tag_set(page + i, tag);
-	kasan_unpoison_shadow(page_address(page), PAGE_SIZE << order);
+	kasan_unpoison_memory(page_address(page), PAGE_SIZE << order);
 }
 
 void kasan_free_pages(struct page *page, unsigned int order)
 {
 	if (likely(!PageHighMem(page)))
-		kasan_poison_shadow(page_address(page),
+		kasan_poison_memory(page_address(page),
 				PAGE_SIZE << order,
 				KASAN_FREE_PAGE);
 }
@@ -289,18 +289,18 @@ void kasan_poison_slab(struct page *page)
 
 	for (i = 0; i < compound_nr(page); i++)
 		page_kasan_tag_reset(page + i);
-	kasan_poison_shadow(page_address(page), page_size(page),
+	kasan_poison_memory(page_address(page), page_size(page),
 			KASAN_KMALLOC_REDZONE);
 }
 
 void kasan_unpoison_object_data(struct kmem_cache *cache, void *object)
 {
-	kasan_unpoison_shadow(object, cache->object_size);
+	kasan_unpoison_memory(object, cache->object_size);
 }
 
 void kasan_poison_object_data(struct kmem_cache *cache, void *object)
 {
-	kasan_poison_shadow(object,
+	kasan_poison_memory(object,
 			round_up(cache->object_size, KASAN_SHADOW_SCALE_SIZE),
 			KASAN_KMALLOC_REDZONE);
 }
@@ -413,7 +413,7 @@ static bool __kasan_slab_free(struct kmem_cache *cache, void *object,
 	}
 
 	rounded_up_size = round_up(cache->object_size, KASAN_SHADOW_SCALE_SIZE);
-	kasan_poison_shadow(object, rounded_up_size, KASAN_KMALLOC_FREE);
+	kasan_poison_memory(object, rounded_up_size, KASAN_KMALLOC_FREE);
 
 	if ((IS_ENABLED(CONFIG_KASAN_GENERIC) && !quarantine) ||
 			unlikely(!(cache->flags & SLAB_KASAN)))
@@ -453,8 +453,8 @@ static void *__kasan_kmalloc(struct kmem_cache *cache, const void *object,
 		tag = assign_tag(cache, object, false, keep_tag);
 
 	/* Tag is ignored in set_tag without CONFIG_KASAN_SW_TAGS */
-	kasan_unpoison_shadow(set_tag(object, tag), size);
-	kasan_poison_shadow((void *)redzone_start, redzone_end - redzone_start,
+	kasan_unpoison_memory(set_tag(object, tag), size);
+	kasan_poison_memory((void *)redzone_start, redzone_end - redzone_start,
 		KASAN_KMALLOC_REDZONE);
 
 	if (cache->flags & SLAB_KASAN)
@@ -494,8 +494,8 @@ void * __must_check kasan_kmalloc_large(const void *ptr, size_t size,
 				KASAN_SHADOW_SCALE_SIZE);
 	redzone_end = (unsigned long)ptr + page_size(page);
 
-	kasan_unpoison_shadow(ptr, size);
-	kasan_poison_shadow((void *)redzone_start, redzone_end - redzone_start,
+	kasan_unpoison_memory(ptr, size);
+	kasan_poison_memory((void *)redzone_start, redzone_end - redzone_start,
 		KASAN_PAGE_REDZONE);
 
 	return (void *)ptr;
@@ -528,7 +528,7 @@ void kasan_poison_kfree(void *ptr, unsigned long ip)
 			kasan_report_invalid_free(ptr, ip);
 			return;
 		}
-		kasan_poison_shadow(ptr, page_size(page), KASAN_FREE_PAGE);
+		kasan_poison_memory(ptr, page_size(page), KASAN_FREE_PAGE);
 	} else {
 		__kasan_slab_free(page->slab_cache, ptr, ip, false);
 	}
@@ -714,7 +714,7 @@ int kasan_populate_vmalloc(unsigned long addr, unsigned long size)
 	 * // vmalloc() allocates memory
 	 * // let a = area->addr
 	 * // we reach kasan_populate_vmalloc
-	 * // and call kasan_unpoison_shadow:
+	 * // and call kasan_unpoison_memory:
 	 * STORE shadow(a), unpoison_val
 	 * ...
 	 * STORE shadow(a+99), unpoison_val	x = LOAD p
@@ -749,7 +749,7 @@ void kasan_poison_vmalloc(const void *start, unsigned long size)
 		return;
 
 	size = round_up(size, KASAN_SHADOW_SCALE_SIZE);
-	kasan_poison_shadow(start, size, KASAN_VMALLOC_INVALID);
+	kasan_poison_memory(start, size, KASAN_VMALLOC_INVALID);
 }
 
 void kasan_unpoison_vmalloc(const void *start, unsigned long size)
@@ -757,7 +757,7 @@ void kasan_unpoison_vmalloc(const void *start, unsigned long size)
 	if (!is_vmalloc_or_module_addr(start))
 		return;
 
-	kasan_unpoison_shadow(start, size);
+	kasan_unpoison_memory(start, size);
 }
 
 static int kasan_depopulate_vmalloc_pte(pte_t *ptep, unsigned long addr,
mm/kasan/generic.c +6 -6
index 248264b9cb76..4b5f905198d8 100644
@@ -207,9 +207,9 @@ static void register_global(struct kasan_global *global)
 {
 	size_t aligned_size = round_up(global->size, KASAN_SHADOW_SCALE_SIZE);
 
-	kasan_unpoison_shadow(global->beg, global->size);
+	kasan_unpoison_memory(global->beg, global->size);
 
-	kasan_poison_shadow(global->beg + aligned_size,
+	kasan_poison_memory(global->beg + aligned_size,
 		global->size_with_redzone - aligned_size,
 		KASAN_GLOBAL_REDZONE);
 }
@@ -290,11 +290,11 @@ void __asan_alloca_poison(unsigned long addr, size_t size)
 
 	WARN_ON(!IS_ALIGNED(addr, KASAN_ALLOCA_REDZONE_SIZE));
 
-	kasan_unpoison_shadow((const void *)(addr + rounded_down_size),
+	kasan_unpoison_memory((const void *)(addr + rounded_down_size),
 			      size - rounded_down_size);
-	kasan_poison_shadow(left_redzone, KASAN_ALLOCA_REDZONE_SIZE,
+	kasan_poison_memory(left_redzone, KASAN_ALLOCA_REDZONE_SIZE,
 			KASAN_ALLOCA_LEFT);
-	kasan_poison_shadow(right_redzone,
+	kasan_poison_memory(right_redzone,
 			padding_size + KASAN_ALLOCA_REDZONE_SIZE,
 			KASAN_ALLOCA_RIGHT);
 }
@@ -306,7 +306,7 @@ void __asan_allocas_unpoison(const void *stack_top, const void *stack_bottom)
 	if (unlikely(!stack_top || stack_top > stack_bottom))
 		return;
 
-	kasan_unpoison_shadow(stack_top, stack_bottom - stack_top);
+	kasan_unpoison_memory(stack_top, stack_bottom - stack_top);
 }
 EXPORT_SYMBOL(__asan_allocas_unpoison);
 
mm/kasan/kasan.h +1 -1
index ac499456740f..03450d3b31f7 100644
@@ -150,7 +150,7 @@ static inline bool addr_has_shadow(const void *addr)
 	return (addr >= kasan_shadow_to_mem((void *)KASAN_SHADOW_START));
 }
 
-void kasan_poison_shadow(const void *address, size_t size, u8 value);
+void kasan_poison_memory(const void *address, size_t size, u8 value);
 
 /**
  * check_memory_region - Check memory region, and report if invalid access.
mm/kasan/tags.c +1 -1
index e02a36a51f42..4d5a1fe8251f 100644
@@ -158,7 +158,7 @@ EXPORT_SYMBOL(__hwasan_storeN_noabort);
 
 void __hwasan_tag_memory(unsigned long addr, u8 tag, unsigned long size)
 {
-	kasan_poison_shadow((void *)addr, size, tag);
+	kasan_poison_memory((void *)addr, size, tag);
 }
 EXPORT_SYMBOL(__hwasan_tag_memory);
 
mm/slab_common.c +1 -1
index 37d48a56431d..24bbf3704a51 100644
@@ -1772,7 +1772,7 @@ size_t ksize(const void *objp)
 	 * We assume that ksize callers could use whole allocated area,
 	 * so we need to unpoison this area.
 	 */
-	kasan_unpoison_shadow(objp, size);
+	kasan_unpoison_memory(objp, size);
 	return size;
 }
 EXPORT_SYMBOL(ksize);
Signature · 1 line
2.28.0.220.ged08abb693-goog
#7 lore raw

PATCH 5/35 kasan: rename KASAN_SHADOW_* to KASAN_GRANULE_*

In reply to Andrey Konovalov

This is a preparatory commit for the upcoming addition of a new hardware tag-based (MTE-based) KASAN mode.

The new mode won't be using shadow memory, but will still use the concept of memory granules. Rename KASAN_SHADOW_SCALE_SIZE to KASAN_GRANULE_SIZE, and KASAN_SHADOW_MASK to KASAN_GRANULE_MASK.

Also use MASK when used as a mask, otherwise use SIZE.

No functional changes.

---
 Documentation/dev-tools/kasan.rst |  2 +-
 lib/test_kasan.c                  |  2 +-
 mm/kasan/common.c                 | 39 ++++++++++++++++---------------
 mm/kasan/generic.c                | 14 +++++------
 mm/kasan/generic_report.c         |  8 +++----
 mm/kasan/init.c                   |  8 +++----
 mm/kasan/kasan.h                  |  4 ++--
 mm/kasan/report.c                 | 10 ++++----
 mm/kasan/tags_report.c            |  2 +-
 9 files changed, 45 insertions(+), 44 deletions(-)
Documentation/dev-tools/kasan.rst +1 -1
index 38fd5681fade..a3030fc6afe5 100644
@@ -264,7 +264,7 @@ Most mappings in vmalloc space are small, requiring less than a full
 page of shadow space. Allocating a full shadow page per mapping would
 therefore be wasteful. Furthermore, to ensure that different mappings
 use different shadow pages, mappings would have to be aligned to
-``KASAN_SHADOW_SCALE_SIZE * PAGE_SIZE``.
+``KASAN_GRANULE_SIZE * PAGE_SIZE``.
 
 Instead, we share backing space across multiple mappings. We allocate
 a backing page when a mapping in vmalloc space uses a particular page
lib/test_kasan.c +1 -1
index 5d3f496893ef..247a14f40016 100644
@@ -25,7 +25,7 @@
 
 #include "../mm/kasan/kasan.h"
 
-#define OOB_TAG_OFF (IS_ENABLED(CONFIG_KASAN_GENERIC) ? 0 : KASAN_SHADOW_SCALE_SIZE)
+#define OOB_TAG_OFF (IS_ENABLED(CONFIG_KASAN_GENERIC) ? 0 : KASAN_GRANULE_SIZE)
 
 /*
  * We assign some test results to these globals to make sure the tests
mm/kasan/common.c +20 -19
index 65933b27df81..c9daf2c33651 100644
@@ -111,7 +111,7 @@ void *memcpy(void *dest, const void *src, size_t len)
 
 /*
  * Poisons the shadow memory for 'size' bytes starting from 'addr'.
- * Memory addresses should be aligned to KASAN_SHADOW_SCALE_SIZE.
+ * Memory addresses should be aligned to KASAN_GRANULE_SIZE.
  */
 void kasan_poison_memory(const void *address, size_t size, u8 value)
 {
@@ -143,13 +143,13 @@ void kasan_unpoison_memory(const void *address, size_t size)
 
 	kasan_poison_memory(address, size, tag);
 
-	if (size & KASAN_SHADOW_MASK) {
+	if (size & KASAN_GRANULE_MASK) {
 		u8 *shadow = (u8 *)kasan_mem_to_shadow(address + size);
 
 		if (IS_ENABLED(CONFIG_KASAN_SW_TAGS))
 			*shadow = tag;
 		else
-			*shadow = size & KASAN_SHADOW_MASK;
+			*shadow = size & KASAN_GRANULE_MASK;
 	}
 }
 
@@ -301,7 +301,7 @@ void kasan_unpoison_object_data(struct kmem_cache *cache, void *object)
 void kasan_poison_object_data(struct kmem_cache *cache, void *object)
 {
 	kasan_poison_memory(object,
-			round_up(cache->object_size, KASAN_SHADOW_SCALE_SIZE),
+			round_up(cache->object_size, KASAN_GRANULE_SIZE),
 			KASAN_KMALLOC_REDZONE);
 }
 
@@ -373,7 +373,7 @@ static inline bool shadow_invalid(u8 tag, s8 shadow_byte)
 {
 	if (IS_ENABLED(CONFIG_KASAN_GENERIC))
 		return shadow_byte < 0 ||
-			shadow_byte >= KASAN_SHADOW_SCALE_SIZE;
+			shadow_byte >= KASAN_GRANULE_SIZE;
 
 	/* else CONFIG_KASAN_SW_TAGS: */
 	if ((u8)shadow_byte == KASAN_TAG_INVALID)
@@ -412,7 +412,7 @@ static bool __kasan_slab_free(struct kmem_cache *cache, void *object,
 		return true;
 	}
 
-	rounded_up_size = round_up(cache->object_size, KASAN_SHADOW_SCALE_SIZE);
+	rounded_up_size = round_up(cache->object_size, KASAN_GRANULE_SIZE);
 	kasan_poison_memory(object, rounded_up_size, KASAN_KMALLOC_FREE);
 
 	if ((IS_ENABLED(CONFIG_KASAN_GENERIC) && !quarantine) ||
@@ -445,9 +445,9 @@ static void *__kasan_kmalloc(struct kmem_cache *cache, const void *object,
 		return NULL;
 
 	redzone_start = round_up((unsigned long)(object + size),
-				KASAN_SHADOW_SCALE_SIZE);
+				KASAN_GRANULE_SIZE);
 	redzone_end = round_up((unsigned long)object + cache->object_size,
-				KASAN_SHADOW_SCALE_SIZE);
+				KASAN_GRANULE_SIZE);
 
 	if (IS_ENABLED(CONFIG_KASAN_SW_TAGS))
 		tag = assign_tag(cache, object, false, keep_tag);
@@ -491,7 +491,7 @@ void * __must_check kasan_kmalloc_large(const void *ptr, size_t size,
 
 	page = virt_to_page(ptr);
 	redzone_start = round_up((unsigned long)(ptr + size),
-				KASAN_SHADOW_SCALE_SIZE);
+				KASAN_GRANULE_SIZE);
 	redzone_end = (unsigned long)ptr + page_size(page);
 
 	kasan_unpoison_memory(ptr, size);
@@ -589,8 +589,8 @@ static int __meminit kasan_mem_notifier(struct notifier_block *nb,
 	shadow_size = nr_shadow_pages << PAGE_SHIFT;
 	shadow_end = shadow_start + shadow_size;
 
-	if (WARN_ON(mem_data->nr_pages % KASAN_SHADOW_SCALE_SIZE) ||
-		WARN_ON(start_kaddr % (KASAN_SHADOW_SCALE_SIZE << PAGE_SHIFT)))
+	if (WARN_ON(mem_data->nr_pages % KASAN_GRANULE_SIZE) ||
+		WARN_ON(start_kaddr % (KASAN_GRANULE_SIZE << PAGE_SHIFT)))
 		return NOTIFY_BAD;
 
 	switch (action) {
@@ -748,7 +748,7 @@ void kasan_poison_vmalloc(const void *start, unsigned long size)
 	if (!is_vmalloc_or_module_addr(start))
 		return;
 
-	size = round_up(size, KASAN_SHADOW_SCALE_SIZE);
+	size = round_up(size, KASAN_GRANULE_SIZE);
 	kasan_poison_memory(start, size, KASAN_VMALLOC_INVALID);
 }
 
@@ -861,22 +861,22 @@ void kasan_release_vmalloc(unsigned long start, unsigned long end,
 	unsigned long region_start, region_end;
 	unsigned long size;
 
-	region_start = ALIGN(start, PAGE_SIZE * KASAN_SHADOW_SCALE_SIZE);
-	region_end = ALIGN_DOWN(end, PAGE_SIZE * KASAN_SHADOW_SCALE_SIZE);
+	region_start = ALIGN(start, PAGE_SIZE * KASAN_GRANULE_SIZE);
+	region_end = ALIGN_DOWN(end, PAGE_SIZE * KASAN_GRANULE_SIZE);
 
 	free_region_start = ALIGN(free_region_start,
-				  PAGE_SIZE * KASAN_SHADOW_SCALE_SIZE);
+				  PAGE_SIZE * KASAN_GRANULE_SIZE);
 
 	if (start != region_start &&
 	    free_region_start < region_start)
-		region_start -= PAGE_SIZE * KASAN_SHADOW_SCALE_SIZE;
+		region_start -= PAGE_SIZE * KASAN_GRANULE_SIZE;
 
 	free_region_end = ALIGN_DOWN(free_region_end,
-				     PAGE_SIZE * KASAN_SHADOW_SCALE_SIZE);
+				     PAGE_SIZE * KASAN_GRANULE_SIZE);
 
 	if (end != region_end &&
 	    free_region_end > region_end)
-		region_end += PAGE_SIZE * KASAN_SHADOW_SCALE_SIZE;
+		region_end += PAGE_SIZE * KASAN_GRANULE_SIZE;
 
 	shadow_start = kasan_mem_to_shadow((void *)region_start);
 	shadow_end = kasan_mem_to_shadow((void *)region_end);
@@ -902,7 +902,8 @@ int kasan_module_alloc(void *addr, size_t size)
 	unsigned long shadow_start;
 
 	shadow_start = (unsigned long)kasan_mem_to_shadow(addr);
-	scaled_size = (size + KASAN_SHADOW_MASK) >> KASAN_SHADOW_SCALE_SHIFT;
+	scaled_size = (size + KASAN_GRANULE_SIZE - 1) >>
+				KASAN_SHADOW_SCALE_SHIFT;
 	shadow_size = round_up(scaled_size, PAGE_SIZE);
 
 	if (WARN_ON(!PAGE_ALIGNED(shadow_start)))
mm/kasan/generic.c +7 -7
index 4b5f905198d8..f6d68aa9872f 100644
@@ -51,7 +51,7 @@ static __always_inline bool memory_is_poisoned_1(unsigned long addr)
 	s8 shadow_value = *(s8 *)kasan_mem_to_shadow((void *)addr);
 
 	if (unlikely(shadow_value)) {
-		s8 last_accessible_byte = addr & KASAN_SHADOW_MASK;
+		s8 last_accessible_byte = addr & KASAN_GRANULE_MASK;
 		return unlikely(last_accessible_byte >= shadow_value);
 	}
 
@@ -67,7 +67,7 @@ static __always_inline bool memory_is_poisoned_2_4_8(unsigned long addr,
 	 * Access crosses 8(shadow size)-byte boundary. Such access maps
 	 * into 2 shadow bytes, so we need to check them both.
 	 */
-	if (unlikely(((addr + size - 1) & KASAN_SHADOW_MASK) < size - 1))
+	if (unlikely(((addr + size - 1) & KASAN_GRANULE_MASK) < size - 1))
 		return *shadow_addr || memory_is_poisoned_1(addr + size - 1);
 
 	return memory_is_poisoned_1(addr + size - 1);
@@ -78,7 +78,7 @@ static __always_inline bool memory_is_poisoned_16(unsigned long addr)
 	u16 *shadow_addr = (u16 *)kasan_mem_to_shadow((void *)addr);
 
 	/* Unaligned 16-bytes access maps into 3 shadow bytes. */
-	if (unlikely(!IS_ALIGNED(addr, KASAN_SHADOW_SCALE_SIZE)))
+	if (unlikely(!IS_ALIGNED(addr, KASAN_GRANULE_SIZE)))
 		return *shadow_addr || memory_is_poisoned_1(addr + 15);
 
 	return *shadow_addr;
@@ -139,7 +139,7 @@ static __always_inline bool memory_is_poisoned_n(unsigned long addr,
 		s8 *last_shadow = (s8 *)kasan_mem_to_shadow((void *)last_byte);
 
 		if (unlikely(ret != (unsigned long)last_shadow ||
-			((long)(last_byte & KASAN_SHADOW_MASK) >= *last_shadow)))
+			((long)(last_byte & KASAN_GRANULE_MASK) >= *last_shadow)))
 			return true;
 	}
 	return false;
@@ -205,7 +205,7 @@ void kasan_cache_shutdown(struct kmem_cache *cache)
 
 static void register_global(struct kasan_global *global)
 {
-	size_t aligned_size = round_up(global->size, KASAN_SHADOW_SCALE_SIZE);
+	size_t aligned_size = round_up(global->size, KASAN_GRANULE_SIZE);
 
 	kasan_unpoison_memory(global->beg, global->size);
 
@@ -279,10 +279,10 @@ EXPORT_SYMBOL(__asan_handle_no_return);
 /* Emitted by compiler to poison alloca()ed objects. */
 void __asan_alloca_poison(unsigned long addr, size_t size)
 {
-	size_t rounded_up_size = round_up(size, KASAN_SHADOW_SCALE_SIZE);
+	size_t rounded_up_size = round_up(size, KASAN_GRANULE_SIZE);
 	size_t padding_size = round_up(size, KASAN_ALLOCA_REDZONE_SIZE) -
 			rounded_up_size;
-	size_t rounded_down_size = round_down(size, KASAN_SHADOW_SCALE_SIZE);
+	size_t rounded_down_size = round_down(size, KASAN_GRANULE_SIZE);
 
 	const void *left_redzone = (const void *)(addr -
 			KASAN_ALLOCA_REDZONE_SIZE);
mm/kasan/generic_report.c +4 -4
index a38c7a9e192a..4dce1633b082 100644
@@ -39,7 +39,7 @@ void *find_first_bad_addr(void *addr, size_t size)
 	void *p = addr;
 
 	while (p < addr + size && !(*(u8 *)kasan_mem_to_shadow(p)))
-		p += KASAN_SHADOW_SCALE_SIZE;
+		p += KASAN_GRANULE_SIZE;
 	return p;
 }
 
@@ -51,14 +51,14 @@ static const char *get_shadow_bug_type(struct kasan_access_info *info)
 	shadow_addr = (u8 *)kasan_mem_to_shadow(info->first_bad_addr);
 
 	/*
-	 * If shadow byte value is in [0, KASAN_SHADOW_SCALE_SIZE) we can look
+	 * If shadow byte value is in [0, KASAN_GRANULE_SIZE) we can look
 	 * at the next shadow byte to determine the type of the bad access.
 	 */
-	if (*shadow_addr > 0 && *shadow_addr <= KASAN_SHADOW_SCALE_SIZE - 1)
+	if (*shadow_addr > 0 && *shadow_addr <= KASAN_GRANULE_SIZE - 1)
 		shadow_addr++;
 
 	switch (*shadow_addr) {
-	case 0 ... KASAN_SHADOW_SCALE_SIZE - 1:
+	case 0 ... KASAN_GRANULE_SIZE - 1:
 		/*
 		 * In theory it's still possible to see these shadow values
 		 * due to a data race in the kernel code.
mm/kasan/init.c +4 -4
index fe6be0be1f76..754b641c83c7 100644
@@ -447,8 +447,8 @@ void kasan_remove_zero_shadow(void *start, unsigned long size)
 	end = addr + (size >> KASAN_SHADOW_SCALE_SHIFT);
 
 	if (WARN_ON((unsigned long)start %
-			(KASAN_SHADOW_SCALE_SIZE * PAGE_SIZE)) ||
-	    WARN_ON(size % (KASAN_SHADOW_SCALE_SIZE * PAGE_SIZE)))
+			(KASAN_GRANULE_SIZE * PAGE_SIZE)) ||
+	    WARN_ON(size % (KASAN_GRANULE_SIZE * PAGE_SIZE)))
 		return;
 
 	for (; addr < end; addr = next) {
@@ -482,8 +482,8 @@ int kasan_add_zero_shadow(void *start, unsigned long size)
 	shadow_end = shadow_start + (size >> KASAN_SHADOW_SCALE_SHIFT);
 
 	if (WARN_ON((unsigned long)start %
-			(KASAN_SHADOW_SCALE_SIZE * PAGE_SIZE)) ||
-	    WARN_ON(size % (KASAN_SHADOW_SCALE_SIZE * PAGE_SIZE)))
+			(KASAN_GRANULE_SIZE * PAGE_SIZE)) ||
+	    WARN_ON(size % (KASAN_GRANULE_SIZE * PAGE_SIZE)))
 		return -EINVAL;
 
 	ret = kasan_populate_early_shadow(shadow_start, shadow_end);
mm/kasan/kasan.h +2 -2
index 03450d3b31f7..c31e2c739301 100644
@@ -5,8 +5,8 @@
 #include <linux/kasan.h>
 #include <linux/stackdepot.h>
 
-#define KASAN_SHADOW_SCALE_SIZE (1UL << KASAN_SHADOW_SCALE_SHIFT)
-#define KASAN_SHADOW_MASK       (KASAN_SHADOW_SCALE_SIZE - 1)
+#define KASAN_GRANULE_SIZE	(1UL << KASAN_SHADOW_SCALE_SHIFT)
+#define KASAN_GRANULE_MASK	(KASAN_GRANULE_SIZE - 1)
 
 #define KASAN_TAG_KERNEL	0xFF /* native kernel pointers tag */
 #define KASAN_TAG_INVALID	0xFE /* inaccessible memory tag */
mm/kasan/report.c +5 -5
index 4f49fa6cd1aa..7c025d792e2f 100644
@@ -317,24 +317,24 @@ static bool __must_check get_address_stack_frame_info(const void *addr,
 		return false;
 
 	aligned_addr = round_down((unsigned long)addr, sizeof(long));
-	mem_ptr = round_down(aligned_addr, KASAN_SHADOW_SCALE_SIZE);
+	mem_ptr = round_down(aligned_addr, KASAN_GRANULE_SIZE);
 	shadow_ptr = kasan_mem_to_shadow((void *)aligned_addr);
 	shadow_bottom = kasan_mem_to_shadow(end_of_stack(current));
 
 	while (shadow_ptr >= shadow_bottom && *shadow_ptr != KASAN_STACK_LEFT) {
 		shadow_ptr--;
-		mem_ptr -= KASAN_SHADOW_SCALE_SIZE;
+		mem_ptr -= KASAN_GRANULE_SIZE;
 	}
 
 	while (shadow_ptr >= shadow_bottom && *shadow_ptr == KASAN_STACK_LEFT) {
 		shadow_ptr--;
-		mem_ptr -= KASAN_SHADOW_SCALE_SIZE;
+		mem_ptr -= KASAN_GRANULE_SIZE;
 	}
 
 	if (shadow_ptr < shadow_bottom)
 		return false;
 
-	frame = (const unsigned long *)(mem_ptr + KASAN_SHADOW_SCALE_SIZE);
+	frame = (const unsigned long *)(mem_ptr + KASAN_GRANULE_SIZE);
 	if (frame[0] != KASAN_CURRENT_STACK_FRAME_MAGIC) {
 		pr_err("KASAN internal error: frame info validation failed; invalid marker: %lu\n",
 		       frame[0]);
@@ -572,6 +572,6 @@ void kasan_non_canonical_hook(unsigned long addr)
 	else
 		bug_type = "maybe wild-memory-access";
 	pr_alert("KASAN: %s in range [0x%016lx-0x%016lx]\n", bug_type,
-		 orig_addr, orig_addr + KASAN_SHADOW_MASK);
+		 orig_addr, orig_addr + KASAN_GRANULE_SIZE - 1);
 }
 #endif
mm/kasan/tags_report.c +1 -1
index bee43717d6f0..6ddb55676a7c 100644
@@ -81,7 +81,7 @@ void *find_first_bad_addr(void *addr, size_t size)
 	void *end = p + size;
 
 	while (p < end && tag == *(u8 *)kasan_mem_to_shadow(p))
-		p += KASAN_SHADOW_SCALE_SIZE;
+		p += KASAN_GRANULE_SIZE;
 	return p;
 }
 
Signature · 1 line
2.28.0.220.ged08abb693-goog
#8 lore raw

PATCH 6/35 kasan: only build init.c for software modes

In reply to Andrey Konovalov

This is a preparatory commit for the upcoming addition of a new hardware tag-based (MTE-based) KASAN mode.

The new mode won't be using shadow memory, so only build init.c that contains shadow initialization code for software modes.

No functional changes for software modes.

---
 mm/kasan/Makefile | 6 +++---
 mm/kasan/init.c   | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)
mm/kasan/Makefile +3 -3
index d532c2587731..b5517de7fc87 100644
@@ -29,6 +29,6 @@ CFLAGS_report.o := $(CC_FLAGS_KASAN_RUNTIME)
 CFLAGS_tags.o := $(CC_FLAGS_KASAN_RUNTIME)
 CFLAGS_tags_report.o := $(CC_FLAGS_KASAN_RUNTIME)
 
-obj-$(CONFIG_KASAN) := common.o init.o report.o
-obj-$(CONFIG_KASAN_GENERIC) += generic.o generic_report.o quarantine.o
-obj-$(CONFIG_KASAN_SW_TAGS) += tags.o tags_report.o
+obj-$(CONFIG_KASAN) := common.o report.o
+obj-$(CONFIG_KASAN_GENERIC) += init.o generic.o generic_report.o quarantine.o
+obj-$(CONFIG_KASAN_SW_TAGS) += init.o tags.o tags_report.o
mm/kasan/init.c +1 -1
index 754b641c83c7..20f5e1ab8d95 100644
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * This file contains some kasan initialization code.
+ * This file contains KASAN shadow initialization code.
  *
  * Copyright (c) 2015 Samsung Electronics Co., Ltd.
  * Author: Andrey Ryabinin <[email protected]>
Signature · 1 line
2.28.0.220.ged08abb693-goog
#9 lore raw

PATCH 7/35 kasan: split out shadow.c from common.c

In reply to Andrey Konovalov

This is a preparatory commit for the upcoming addition of a new hardware tag-based (MTE-based) KASAN mode.

The new mode won't be using shadow memory. Move all shadow-related code to shadow.c, which is only enabled for software KASAN modes that use shadow memory.

No functional changes for software modes.

---
 mm/kasan/Makefile |   6 +-
 mm/kasan/common.c | 486 +------------------------------------------
 mm/kasan/shadow.c | 509 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 514 insertions(+), 487 deletions(-)
 create mode 100644 mm/kasan/shadow.c
mm/kasan/Makefile +4 -2
index b5517de7fc87..40366d706b7c 100644
@@ -10,6 +10,7 @@ CFLAGS_REMOVE_generic_report.o = $(CC_FLAGS_FTRACE)
 CFLAGS_REMOVE_init.o = $(CC_FLAGS_FTRACE)
 CFLAGS_REMOVE_quarantine.o = $(CC_FLAGS_FTRACE)
 CFLAGS_REMOVE_report.o = $(CC_FLAGS_FTRACE)
+CFLAGS_REMOVE_shadow.o = $(CC_FLAGS_FTRACE)
 CFLAGS_REMOVE_tags.o = $(CC_FLAGS_FTRACE)
 CFLAGS_REMOVE_tags_report.o = $(CC_FLAGS_FTRACE)
 
@@ -26,9 +27,10 @@ CFLAGS_generic_report.o := $(CC_FLAGS_KASAN_RUNTIME)
 CFLAGS_init.o := $(CC_FLAGS_KASAN_RUNTIME)
 CFLAGS_quarantine.o := $(CC_FLAGS_KASAN_RUNTIME)
 CFLAGS_report.o := $(CC_FLAGS_KASAN_RUNTIME)
+CFLAGS_shadow.o := $(CC_FLAGS_KASAN_RUNTIME)
 CFLAGS_tags.o := $(CC_FLAGS_KASAN_RUNTIME)
 CFLAGS_tags_report.o := $(CC_FLAGS_KASAN_RUNTIME)
 
 obj-$(CONFIG_KASAN) := common.o report.o
-obj-$(CONFIG_KASAN_GENERIC) += init.o generic.o generic_report.o quarantine.o
-obj-$(CONFIG_KASAN_SW_TAGS) += init.o tags.o tags_report.o
+obj-$(CONFIG_KASAN_GENERIC) += init.o generic.o generic_report.o shadow.o quarantine.o
+obj-$(CONFIG_KASAN_SW_TAGS) += init.o shadow.o tags.o tags_report.o
mm/kasan/common.c +1 -485

514 lines not on this page · raw message

mm/kasan/shadow.c new file +509 -0

509 lines not on this page · raw message

Signature · 1 line
2.28.0.220.ged08abb693-goog
#10 lore raw

PATCH 8/35 kasan: rename generic/tags_report.c files

In reply to Andrey Konovalov

Rename generic_report.c to report_generic.c and tags_report.c to report_tags.c, as their content is more relevant to report.c file, then to generic.c or tags.c.

No functional changes.

---
 mm/kasan/Makefile                               | 12 ++++++------
 mm/kasan/report.c                               |  2 +-
 mm/kasan/{generic_report.c => report_generic.c} |  0
 mm/kasan/{tags_report.c => report_tags.c}       |  0
 4 files changed, 7 insertions(+), 7 deletions(-)
 rename mm/kasan/{generic_report.c => report_generic.c} (100%)
 rename mm/kasan/{tags_report.c => report_tags.c} (100%)
mm/kasan/Makefile +6 -6
index 40366d706b7c..007c824f6f43 100644
@@ -6,13 +6,13 @@ KCOV_INSTRUMENT := n
 # Disable ftrace to avoid recursion.
 CFLAGS_REMOVE_common.o = $(CC_FLAGS_FTRACE)
 CFLAGS_REMOVE_generic.o = $(CC_FLAGS_FTRACE)
-CFLAGS_REMOVE_generic_report.o = $(CC_FLAGS_FTRACE)
 CFLAGS_REMOVE_init.o = $(CC_FLAGS_FTRACE)
 CFLAGS_REMOVE_quarantine.o = $(CC_FLAGS_FTRACE)
 CFLAGS_REMOVE_report.o = $(CC_FLAGS_FTRACE)
+CFLAGS_REMOVE_report_generic.o = $(CC_FLAGS_FTRACE)
+CFLAGS_REMOVE_report_tags.o = $(CC_FLAGS_FTRACE)
 CFLAGS_REMOVE_shadow.o = $(CC_FLAGS_FTRACE)
 CFLAGS_REMOVE_tags.o = $(CC_FLAGS_FTRACE)
-CFLAGS_REMOVE_tags_report.o = $(CC_FLAGS_FTRACE)
 
 # Function splitter causes unnecessary splits in __asan_load1/__asan_store1
 # see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63533
@@ -23,14 +23,14 @@ CC_FLAGS_KASAN_RUNTIME += -DDISABLE_BRANCH_PROFILING
 
 CFLAGS_common.o := $(CC_FLAGS_KASAN_RUNTIME)
 CFLAGS_generic.o := $(CC_FLAGS_KASAN_RUNTIME)
-CFLAGS_generic_report.o := $(CC_FLAGS_KASAN_RUNTIME)
 CFLAGS_init.o := $(CC_FLAGS_KASAN_RUNTIME)
 CFLAGS_quarantine.o := $(CC_FLAGS_KASAN_RUNTIME)
 CFLAGS_report.o := $(CC_FLAGS_KASAN_RUNTIME)
+CFLAGS_report_generic.o := $(CC_FLAGS_KASAN_RUNTIME)
+CFLAGS_report_tags.o := $(CC_FLAGS_KASAN_RUNTIME)
 CFLAGS_shadow.o := $(CC_FLAGS_KASAN_RUNTIME)
 CFLAGS_tags.o := $(CC_FLAGS_KASAN_RUNTIME)
-CFLAGS_tags_report.o := $(CC_FLAGS_KASAN_RUNTIME)
 
 obj-$(CONFIG_KASAN) := common.o report.o
-obj-$(CONFIG_KASAN_GENERIC) += init.o generic.o generic_report.o shadow.o quarantine.o
-obj-$(CONFIG_KASAN_SW_TAGS) += init.o shadow.o tags.o tags_report.o
+obj-$(CONFIG_KASAN_GENERIC) += init.o generic.o report_generic.o shadow.o quarantine.o
+obj-$(CONFIG_KASAN_SW_TAGS) += init.o report_tags.o shadow.o tags.o
mm/kasan/report.c +1 -1
index 7c025d792e2f..f16591ba9e2e 100644
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * This file contains common generic and tag-based KASAN error reporting code.
+ * This file contains common KASAN error reporting code.
  *
  * Copyright (c) 2014 Samsung Electronics Co., Ltd.
  * Author: Andrey Ryabinin <[email protected]>
mm/kasan/report_generic.c renamed from mm/kasan/generic_report.c +0 -0
similarity index 100%
rename from mm/kasan/generic_report.c
rename to mm/kasan/report_generic.c
mm/kasan/report_tags.c renamed from mm/kasan/tags_report.c +0 -0
similarity index 100%
rename from mm/kasan/tags_report.c
rename to mm/kasan/report_tags.c
Signature · 1 line
2.28.0.220.ged08abb693-goog
#11 lore raw

PATCH 9/35 kasan: don't duplicate config dependencies

In reply to Andrey Konovalov

Both KASAN_GENERIC and KASAN_SW_TAGS have common dependencies, move those to KASAN.

---
 lib/Kconfig.kasan | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)
lib/Kconfig.kasan +3 -8
index e1d55331b618..b4cf6c519d71 100644
@@ -24,6 +24,9 @@ menuconfig KASAN
 		   (HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS)
 	depends on (SLUB && SYSFS) || (SLAB && !DEBUG_SLAB)
 	depends on CC_HAS_WORKING_NOSANITIZE_ADDRESS
+	select SLUB_DEBUG if SLUB
+	select CONSTRUCTORS
+	select STACKDEPOT
 	help
 	  Enables KASAN (KernelAddressSANitizer) - runtime memory debugger,
 	  designed to find out-of-bounds accesses and use-after-free bugs.
@@ -46,10 +49,6 @@ choice
 config KASAN_GENERIC
 	bool "Generic mode"
 	depends on HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC
-	depends on (SLUB && SYSFS) || (SLAB && !DEBUG_SLAB)
-	select SLUB_DEBUG if SLUB
-	select CONSTRUCTORS
-	select STACKDEPOT
 	help
 	  Enables generic KASAN mode.
 
@@ -70,10 +69,6 @@ config KASAN_GENERIC
 config KASAN_SW_TAGS
 	bool "Software tag-based mode"
 	depends on HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS
-	depends on (SLUB && SYSFS) || (SLAB && !DEBUG_SLAB)
-	select SLUB_DEBUG if SLUB
-	select CONSTRUCTORS
-	select STACKDEPOT
 	help
 	  Enables software tag-based KASAN mode.
 
Signature · 1 line
2.28.0.220.ged08abb693-goog
#12 lore raw

PATCH 10/35 kasan: hide invalid free check implementation

In reply to Andrey Konovalov

This is a preparatory commit for the upcoming addition of a new hardware tag-based (MTE-based) KASAN mode.

For software KASAN modes the check is based on the value in the shadow memory. Hardware tag-based KASAN won't be using shadow, so hide the implementation of the check in check_invalid_free().

No functional changes for software modes.

---
 mm/kasan/common.c  | 19 +------------------
 mm/kasan/generic.c |  7 +++++++
 mm/kasan/kasan.h   |  2 ++
 mm/kasan/tags.c    | 12 ++++++++++++
 4 files changed, 22 insertions(+), 18 deletions(-)
mm/kasan/common.c +1 -18
index 43a927e70067..a2321d35390e 100644
@@ -277,25 +277,9 @@ void * __must_check kasan_init_slab_obj(struct kmem_cache *cache,
 	return (void *)object;
 }
 
-static inline bool shadow_invalid(u8 tag, s8 shadow_byte)
-{
-	if (IS_ENABLED(CONFIG_KASAN_GENERIC))
-		return shadow_byte < 0 ||
-			shadow_byte >= KASAN_GRANULE_SIZE;
-
-	/* else CONFIG_KASAN_SW_TAGS: */
-	if ((u8)shadow_byte == KASAN_TAG_INVALID)
-		return true;
-	if ((tag != KASAN_TAG_KERNEL) && (tag != (u8)shadow_byte))
-		return true;
-
-	return false;
-}
-
 static bool __kasan_slab_free(struct kmem_cache *cache, void *object,
 			      unsigned long ip, bool quarantine)
 {
-	s8 shadow_byte;
 	u8 tag;
 	void *tagged_object;
 	unsigned long rounded_up_size;
@@ -314,8 +298,7 @@ static bool __kasan_slab_free(struct kmem_cache *cache, void *object,
 	if (unlikely(cache->flags & SLAB_TYPESAFE_BY_RCU))
 		return false;
 
-	shadow_byte = READ_ONCE(*(s8 *)kasan_mem_to_shadow(object));
-	if (shadow_invalid(tag, shadow_byte)) {
+	if (check_invalid_free(tagged_object)) {
 		kasan_report_invalid_free(tagged_object, ip);
 		return true;
 	}
mm/kasan/generic.c +7 -0
index f6d68aa9872f..73f4d786ad5d 100644
@@ -192,6 +192,13 @@ bool check_memory_region(unsigned long addr, size_t size, bool write,
 	return check_memory_region_inline(addr, size, write, ret_ip);
 }
 
+bool check_invalid_free(void *addr)
+{
+	s8 shadow_byte = READ_ONCE(*(s8 *)kasan_mem_to_shadow(addr));
+
+	return shadow_byte < 0 || shadow_byte >= KASAN_GRANULE_SIZE;
+}
+
 void kasan_cache_shrink(struct kmem_cache *cache)
 {
 	quarantine_remove_cache(cache);
mm/kasan/kasan.h +2 -0
index c31e2c739301..cf6a135860f2 100644
@@ -163,6 +163,8 @@ void kasan_poison_memory(const void *address, size_t size, u8 value);
 bool check_memory_region(unsigned long addr, size_t size, bool write,
 				unsigned long ret_ip);
 
+bool check_invalid_free(void *addr);
+
 void *find_first_bad_addr(void *addr, size_t size);
 const char *get_bug_type(struct kasan_access_info *info);
 
mm/kasan/tags.c +12 -0
index 4d5a1fe8251f..feb42c1763b8 100644
@@ -126,6 +126,18 @@ bool check_memory_region(unsigned long addr, size_t size, bool write,
 	return true;
 }
 
+bool check_invalid_free(void *addr)
+{
+	u8 tag = get_tag(addr);
+	u8 shadow_byte = READ_ONCE(*(u8 *)kasan_mem_to_shadow(reset_tag(addr)));
+
+	if (shadow_byte == KASAN_TAG_INVALID)
+		return true;
+	if (tag != KASAN_TAG_KERNEL && tag != shadow_byte)
+		return true;
+	return false;
+}
+
 #define DEFINE_HWASAN_LOAD_STORE(size)					\
 	void __hwasan_load##size##_noabort(unsigned long addr)		\
 	{								\
Signature · 1 line
2.28.0.220.ged08abb693-goog
#13 lore raw

PATCH 11/35 kasan: decode stack frame only with KASAN_STACK_ENABLE

In reply to Andrey Konovalov

Decoding routines aren't needed when CONFIG_KASAN_STACK_ENABLE is not enabled. Currently only generic KASAN mode implements stack error reporting.

No functional changes for software modes.

---
 mm/kasan/kasan.h          |   6 ++
 mm/kasan/report.c         | 162 --------------------------------------
 mm/kasan/report_generic.c | 161 +++++++++++++++++++++++++++++++++++++
 3 files changed, 167 insertions(+), 162 deletions(-)
mm/kasan/kasan.h +6 -0
index cf6a135860f2..15cf3e0018ae 100644
@@ -168,6 +168,12 @@ bool check_invalid_free(void *addr);
 void *find_first_bad_addr(void *addr, size_t size);
 const char *get_bug_type(struct kasan_access_info *info);
 
+#ifdef CONFIG_KASAN_STACK_ENABLE
+void print_address_stack_frame(const void *addr);
+#else
+static inline void print_address_stack_frame(const void *addr) { }
+#endif
+
 bool kasan_report(unsigned long addr, size_t size,
 		bool is_write, unsigned long ip);
 void kasan_report_invalid_free(void *object, unsigned long ip);
mm/kasan/report.c +0 -162

168 lines not on this page · raw message

mm/kasan/report_generic.c +161 -0

167 lines not on this page · raw message

Signature · 1 line
2.28.0.220.ged08abb693-goog
#14 lore raw

PATCH 12/35 kasan, arm64: only init shadow for software modes

In reply to Andrey Konovalov

This is a preparatory commit for the upcoming addition of a new hardware tag-based (MTE-based) KASAN mode.

Hardware tag-based KASAN won't be using shadow memory. Only initialize it when one of the software KASAN modes are enabled.

No functional changes for software modes.

---
 arch/arm64/include/asm/kasan.h |  8 ++++++--
 arch/arm64/mm/kasan_init.c     | 15 ++++++++++++++-
 2 files changed, 20 insertions(+), 3 deletions(-)
arch/arm64/include/asm/kasan.h +6 -2
index b0dc4abc3589..f7ea70d02cab 100644
@@ -13,6 +13,12 @@
 #define arch_kasan_get_tag(addr)	__tag_get(addr)
 
 #ifdef CONFIG_KASAN
+void kasan_init(void);
+#else
+static inline void kasan_init(void) { }
+#endif
+
+#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 
 /*
  * KASAN_SHADOW_START: beginning of the kernel virtual addresses.
@@ -33,12 +39,10 @@
 #define _KASAN_SHADOW_START(va)	(KASAN_SHADOW_END - (1UL << ((va) - KASAN_SHADOW_SCALE_SHIFT)))
 #define KASAN_SHADOW_START      _KASAN_SHADOW_START(vabits_actual)
 
-void kasan_init(void);
 void kasan_copy_shadow(pgd_t *pgdir);
 asmlinkage void kasan_early_init(void);
 
 #else
-static inline void kasan_init(void) { }
 static inline void kasan_copy_shadow(pgd_t *pgdir) { }
 #endif
 
arch/arm64/mm/kasan_init.c +14 -1
index 7291b26ce788..4d35eaf3ec97 100644
@@ -21,6 +21,8 @@
 #include <asm/sections.h>
 #include <asm/tlbflush.h>
 
+#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
+
 static pgd_t tmp_pg_dir[PTRS_PER_PGD] __initdata __aligned(PGD_SIZE);
 
 /*
@@ -208,7 +210,7 @@ static void __init clear_pgds(unsigned long start,
 		set_pgd(pgd_offset_k(start), __pgd(0));
 }
 
-void __init kasan_init(void)
+static void __init kasan_init_shadow(void)
 {
 	u64 kimg_shadow_start, kimg_shadow_end;
 	u64 mod_shadow_start, mod_shadow_end;
@@ -269,6 +271,17 @@ void __init kasan_init(void)
 
 	memset(kasan_early_shadow_page, KASAN_SHADOW_INIT, PAGE_SIZE);
 	cpu_replace_ttbr1(lm_alias(swapper_pg_dir));
+}
+
+#else /* CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS) */
+
+static inline void __init kasan_init_shadow(void) { }
+
+#endif /* CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS */
+
+void __init kasan_init(void)
+{
+	kasan_init_shadow();
 
 	/* At this point kasan is fully initialized. Enable error messages */
 	init_task.kasan_depth = 0;
Signature · 1 line
2.28.0.220.ged08abb693-goog
#15 lore raw

PATCH 13/35 kasan, arm64: only use kasan_depth for software modes

In reply to Andrey Konovalov

This is a preparatory commit for the upcoming addition of a new hardware tag-based (MTE-based) KASAN mode.

Hardware tag-based KASAN won't use kasan_depth. Only define and use it when one of the software KASAN modes are enabled.

No functional changes for software modes.

---
 arch/arm64/mm/kasan_init.c | 11 ++++++++---
 include/linux/kasan.h      | 14 ++++++++++----
 include/linux/sched.h      |  2 +-
 init/init_task.c           |  2 +-
 mm/kasan/common.c          |  2 ++
 mm/kasan/report.c          |  2 ++
 6 files changed, 24 insertions(+), 9 deletions(-)
arch/arm64/mm/kasan_init.c +8 -3
index 4d35eaf3ec97..b6b9d55bb72e 100644
@@ -273,17 +273,22 @@ static void __init kasan_init_shadow(void)
 	cpu_replace_ttbr1(lm_alias(swapper_pg_dir));
 }
 
+void __init kasan_init_depth(void)
+{
+	init_task.kasan_depth = 0;
+}
+
 #else /* CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS) */
 
 static inline void __init kasan_init_shadow(void) { }
 
+static inline void __init kasan_init_depth(void) { }
+
 #endif /* CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS */
 
 void __init kasan_init(void)
 {
 	kasan_init_shadow();
-
-	/* At this point kasan is fully initialized. Enable error messages */
-	init_task.kasan_depth = 0;
+	kasan_init_depth();
 	pr_info("KernelAddressSanitizer initialized\n");
 }
include/linux/kasan.h +10 -4
index 18617d5c4cd7..894f4d9163ee 100644
@@ -52,7 +52,7 @@ static inline void kasan_remove_zero_shadow(void *start,
 
 #endif /* CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS */
 
-#ifdef CONFIG_KASAN
+#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 
 /* Enable reporting bugs after kasan_disable_current() */
 extern void kasan_enable_current(void);
@@ -60,6 +60,15 @@ extern void kasan_enable_current(void);
 /* Disable reporting bugs for current task */
 extern void kasan_disable_current(void);
 
+#else /* CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS */
+
+static inline void kasan_enable_current(void) {}
+static inline void kasan_disable_current(void) {}
+
+#endif /* CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS */
+
+#ifdef CONFIG_KASAN
+
 void kasan_unpoison_memory(const void *address, size_t size);
 
 void kasan_unpoison_task_stack(struct task_struct *task);
@@ -110,9 +119,6 @@ static inline void kasan_unpoison_memory(const void *address, size_t size) {}
 
 static inline void kasan_unpoison_task_stack(struct task_struct *task) {}
 
-static inline void kasan_enable_current(void) {}
-static inline void kasan_disable_current(void) {}
-
 static inline void kasan_alloc_pages(struct page *page, unsigned int order) {}
 static inline void kasan_free_pages(struct page *page, unsigned int order) {}
 
include/linux/sched.h +1 -1
index 692e327d7455..6dca19f2516c 100644
@@ -1194,7 +1194,7 @@ struct task_struct {
 	u64				timer_slack_ns;
 	u64				default_timer_slack_ns;
 
-#ifdef CONFIG_KASAN
+#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 	unsigned int			kasan_depth;
 #endif
 #ifdef CONFIG_KCSAN
init/init_task.c +1 -1
index 15089d15010a..13f1cf21412b 100644
@@ -171,7 +171,7 @@ struct task_struct init_task
 	.numa_group	= NULL,
 	.numa_faults	= NULL,
 #endif
-#ifdef CONFIG_KASAN
+#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 	.kasan_depth	= 1,
 #endif
 #ifdef CONFIG_KCSAN
mm/kasan/common.c +2 -0
index a2321d35390e..41c7f1105eaa 100644
@@ -51,6 +51,7 @@ void kasan_set_track(struct kasan_track *track, gfp_t flags)
 	track->stack = kasan_save_stack(flags);
 }
 
+#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 void kasan_enable_current(void)
 {
 	current->kasan_depth++;
@@ -60,6 +61,7 @@ void kasan_disable_current(void)
 {
 	current->kasan_depth--;
 }
+#endif /* CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS */
 
 static void __kasan_unpoison_stack(struct task_struct *task, const void *sp)
 {
mm/kasan/report.c +2 -0
index ddaf9d14ca81..8463e35b489f 100644
@@ -295,8 +295,10 @@ static void print_shadow_for_address(const void *addr)
 
 static bool report_enabled(void)
 {
+#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 	if (current->kasan_depth)
 		return false;
+#endif
 	if (test_bit(KASAN_BIT_MULTI_SHOT, &kasan_flags))
 		return true;
 	return !test_and_set_bit(KASAN_BIT_REPORTED, &kasan_flags);
Signature · 1 line
2.28.0.220.ged08abb693-goog
#16 lore raw

PATCH 14/35 kasan: rename addr_has_shadow to addr_has_metadata

In reply to Andrey Konovalov

This is a preparatory commit for the upcoming addition of a new hardware tag-based (MTE-based) KASAN mode.

Hardware tag-based KASAN won't be using shadow memory, but will reuse this function. Rename "shadow" to implementation-neutral "metadata".

No functional changes.

---
 mm/kasan/kasan.h          | 2 +-
 mm/kasan/report.c         | 6 +++---
 mm/kasan/report_generic.c | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)
mm/kasan/kasan.h +1 -1
index 15cf3e0018ae..38fa4c202e9a 100644
@@ -145,7 +145,7 @@ static inline const void *kasan_shadow_to_mem(const void *shadow_addr)
 		<< KASAN_SHADOW_SCALE_SHIFT);
 }
 
-static inline bool addr_has_shadow(const void *addr)
+static inline bool addr_has_metadata(const void *addr)
 {
 	return (addr >= kasan_shadow_to_mem((void *)KASAN_SHADOW_START));
 }
mm/kasan/report.c +3 -3
index 8463e35b489f..ada3cfb43764 100644
@@ -334,7 +334,7 @@ static void __kasan_report(unsigned long addr, size_t size, bool is_write,
 	untagged_addr = reset_tag(tagged_addr);
 
 	info.access_addr = tagged_addr;
-	if (addr_has_shadow(untagged_addr))
+	if (addr_has_metadata(untagged_addr))
 		info.first_bad_addr = find_first_bad_addr(tagged_addr, size);
 	else
 		info.first_bad_addr = untagged_addr;
@@ -345,11 +345,11 @@ static void __kasan_report(unsigned long addr, size_t size, bool is_write,
 	start_report(&flags);
 
 	print_error_description(&info);
-	if (addr_has_shadow(untagged_addr))
+	if (addr_has_metadata(untagged_addr))
 		print_tags(get_tag(tagged_addr), info.first_bad_addr);
 	pr_err("\n");
 
-	if (addr_has_shadow(untagged_addr)) {
+	if (addr_has_metadata(untagged_addr)) {
 		print_address_description(untagged_addr, get_tag(tagged_addr));
 		pr_err("\n");
 		print_shadow_for_address(info.first_bad_addr);
mm/kasan/report_generic.c +1 -1
index 427f4ac80cca..29d30fae9421 100644
@@ -122,7 +122,7 @@ const char *get_bug_type(struct kasan_access_info *info)
 	if (info->access_addr + info->access_size < info->access_addr)
 		return "out-of-bounds";
 
-	if (addr_has_shadow(info->access_addr))
+	if (addr_has_metadata(info->access_addr))
 		return get_shadow_bug_type(info);
 	return get_wild_bug_type(info);
 }
Signature · 1 line
2.28.0.220.ged08abb693-goog
#17 lore raw

PATCH 15/35 kasan: rename print_shadow_for_address to print_memory_metadata

In reply to Andrey Konovalov

This is a preparatory commit for the upcoming addition of a new hardware tag-based (MTE-based) KASAN mode.

Hardware tag-based KASAN won't be using shadow memory, but will reuse this function. Rename "shadow" to implementation-neutral "metadata".

No functional changes.

---
 mm/kasan/report.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
mm/kasan/report.c +3 -3
index ada3cfb43764..8ad1ced1607d 100644
@@ -255,7 +255,7 @@ static int shadow_pointer_offset(const void *row, const void *shadow)
 		(shadow - row) / SHADOW_BYTES_PER_BLOCK + 1;
 }
 
-static void print_shadow_for_address(const void *addr)
+static void print_memory_metadata(const void *addr)
 {
 	int i;
 	const void *shadow = kasan_mem_to_shadow(addr);
@@ -316,7 +316,7 @@ void kasan_report_invalid_free(void *object, unsigned long ip)
 	pr_err("\n");
 	print_address_description(object, tag);
 	pr_err("\n");
-	print_shadow_for_address(object);
+	print_memory_metadata(object);
 	end_report(&flags);
 }
 
@@ -352,7 +352,7 @@ static void __kasan_report(unsigned long addr, size_t size, bool is_write,
 	if (addr_has_metadata(untagged_addr)) {
 		print_address_description(untagged_addr, get_tag(tagged_addr));
 		pr_err("\n");
-		print_shadow_for_address(info.first_bad_addr);
+		print_memory_metadata(info.first_bad_addr);
 	} else {
 		dump_stack();
 	}
Signature · 1 line
2.28.0.220.ged08abb693-goog
#18 lore raw

PATCH 16/35 kasan: kasan_non_canonical_hook only for software modes

In reply to Andrey Konovalov

This is a preparatory commit for the upcoming addition of a new hardware tag-based (MTE-based) KASAN mode.

kasan_non_canonical_hook() is only applicable to KASAN modes that use shadow memory, and won't be needed for hardware tag-based KASAN.

No functional changes for software modes.

---
 mm/kasan/report.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
mm/kasan/report.c +2 -1
index 8ad1ced1607d..2cce7c9beea3 100644
@@ -376,7 +376,8 @@ bool kasan_report(unsigned long addr, size_t size, bool is_write,
 	return ret;
 }
 
-#ifdef CONFIG_KASAN_INLINE
+#if (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) && \
+	defined(CONFIG_KASAN_INLINE)
 /*
  * With CONFIG_KASAN_INLINE, accesses to bogus pointers (outside the high
  * canonical half of the address space) cause out-of-bounds shadow memory reads
Signature · 1 line
2.28.0.220.ged08abb693-goog
#19 lore raw

PATCH 17/35 kasan: rename SHADOW layout macros to META

In reply to Andrey Konovalov

This is a preparatory commit for the upcoming addition of a new hardware tag-based (MTE-based) KASAN mode.

Hardware tag-based KASAN won't be using shadow memory, but will reuse these macros. Rename "SHADOW" to implementation-neutral "META".

No functional changes.

---
 mm/kasan/report.c | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)
mm/kasan/report.c +15 -15
index 2cce7c9beea3..6306673e7062 100644
@@ -36,11 +36,11 @@
 #include "kasan.h"
 #include "../slab.h"
 
-/* Shadow layout customization. */
-#define SHADOW_BYTES_PER_BLOCK 1
-#define SHADOW_BLOCKS_PER_ROW 16
-#define SHADOW_BYTES_PER_ROW (SHADOW_BLOCKS_PER_ROW * SHADOW_BYTES_PER_BLOCK)
-#define SHADOW_ROWS_AROUND_ADDR 2
+/* Metadata layout customization. */
+#define META_BYTES_PER_BLOCK 1
+#define META_BLOCKS_PER_ROW 16
+#define META_BYTES_PER_ROW (META_BLOCKS_PER_ROW * META_BYTES_PER_BLOCK)
+#define META_ROWS_AROUND_ADDR 2
 
 static unsigned long kasan_flags;
 
@@ -243,7 +243,7 @@ static void print_address_description(void *addr, u8 tag)
 
 static bool row_is_guilty(const void *row, const void *guilty)
 {
-	return (row <= guilty) && (guilty < row + SHADOW_BYTES_PER_ROW);
+	return (row <= guilty) && (guilty < row + META_BYTES_PER_ROW);
 }
 
 static int shadow_pointer_offset(const void *row, const void *shadow)
@@ -252,7 +252,7 @@ static int shadow_pointer_offset(const void *row, const void *shadow)
 	 *    3 + (BITS_PER_LONG/8)*2 chars.
 	 */
 	return 3 + (BITS_PER_LONG/8)*2 + (shadow - row)*2 +
-		(shadow - row) / SHADOW_BYTES_PER_BLOCK + 1;
+		(shadow - row) / META_BYTES_PER_BLOCK + 1;
 }
 
 static void print_memory_metadata(const void *addr)
@@ -262,15 +262,15 @@ static void print_memory_metadata(const void *addr)
 	const void *shadow_row;
 
 	shadow_row = (void *)round_down((unsigned long)shadow,
-					SHADOW_BYTES_PER_ROW)
-		- SHADOW_ROWS_AROUND_ADDR * SHADOW_BYTES_PER_ROW;
+					META_BYTES_PER_ROW)
+		- META_ROWS_AROUND_ADDR * META_BYTES_PER_ROW;
 
 	pr_err("Memory state around the buggy address:\n");
 
-	for (i = -SHADOW_ROWS_AROUND_ADDR; i <= SHADOW_ROWS_AROUND_ADDR; i++) {
+	for (i = -META_ROWS_AROUND_ADDR; i <= META_ROWS_AROUND_ADDR; i++) {
 		const void *kaddr = kasan_shadow_to_mem(shadow_row);
 		char buffer[4 + (BITS_PER_LONG/8)*2];
-		char shadow_buf[SHADOW_BYTES_PER_ROW];
+		char shadow_buf[META_BYTES_PER_ROW];
 
 		snprintf(buffer, sizeof(buffer),
 			(i == 0) ? ">%px: " : " %px: ", kaddr);
@@ -279,17 +279,17 @@ static void print_memory_metadata(const void *addr)
 		 * function, because generic functions may try to
 		 * access kasan mapping for the passed address.
 		 */
-		memcpy(shadow_buf, shadow_row, SHADOW_BYTES_PER_ROW);
+		memcpy(shadow_buf, shadow_row, META_BYTES_PER_ROW);
 		print_hex_dump(KERN_ERR, buffer,
-			DUMP_PREFIX_NONE, SHADOW_BYTES_PER_ROW, 1,
-			shadow_buf, SHADOW_BYTES_PER_ROW, 0);
+			DUMP_PREFIX_NONE, META_BYTES_PER_ROW, 1,
+			shadow_buf, META_BYTES_PER_ROW, 0);
 
 		if (row_is_guilty(shadow_row, shadow))
 			pr_err("%*c\n",
 				shadow_pointer_offset(shadow_row, shadow),
 				'^');
 
-		shadow_row += SHADOW_BYTES_PER_ROW;
+		shadow_row += META_BYTES_PER_ROW;
 	}
 }
 
Signature · 1 line
2.28.0.220.ged08abb693-goog
#20 lore raw

PATCH 18/35 kasan: separate metadata_fetch_row for each mode

In reply to Andrey Konovalov

This is a preparatory commit for the upcoming addition of a new hardware tag-based (MTE-based) KASAN mode.

Rework print_memory_metadata() to make it agnostic with regard to the way metadata is stored. Allow providing a separate metadata_fetch_row() implementation for each KASAN mode. Hardware tag-based KASAN will provide its own implementation that doesn't use shadow memory.

No functional changes for software modes.

---
 mm/kasan/kasan.h          |  8 ++++++
 mm/kasan/report.c         | 56 +++++++++++++++++++--------------------
 mm/kasan/report_generic.c |  5 ++++
 mm/kasan/report_tags.c    |  5 ++++
 4 files changed, 45 insertions(+), 29 deletions(-)
mm/kasan/kasan.h +8 -0
index 38fa4c202e9a..1d3c7c6ce771 100644
@@ -56,6 +56,13 @@
 #define KASAN_ABI_VERSION 1
 #endif
 
+/* Metadata layout customization. */
+#define META_BYTES_PER_BLOCK 1
+#define META_BLOCKS_PER_ROW 16
+#define META_BYTES_PER_ROW (META_BLOCKS_PER_ROW * META_BYTES_PER_BLOCK)
+#define META_MEM_BYTES_PER_ROW (META_BYTES_PER_ROW * KASAN_GRANULE_SIZE)
+#define META_ROWS_AROUND_ADDR 2
+
 struct kasan_access_info {
 	const void *access_addr;
 	const void *first_bad_addr;
@@ -167,6 +174,7 @@ bool check_invalid_free(void *addr);
 
 void *find_first_bad_addr(void *addr, size_t size);
 const char *get_bug_type(struct kasan_access_info *info);
+void metadata_fetch_row(char *buffer, void *row);
 
 #ifdef CONFIG_KASAN_STACK_ENABLE
 void print_address_stack_frame(const void *addr);
mm/kasan/report.c +27 -29

94 lines not on this page · raw message

mm/kasan/report_generic.c +5 -0
index 29d30fae9421..6524651b5d2e 100644
@@ -127,6 +127,11 @@ const char *get_bug_type(struct kasan_access_info *info)
 	return get_wild_bug_type(info);
 }
 
+void metadata_fetch_row(char *buffer, void *row)
+{
+	memcpy(buffer, kasan_mem_to_shadow(row), META_BYTES_PER_ROW);
+}
+
 #ifdef CONFIG_KASAN_STACK_ENABLE
 static bool __must_check tokenize_frame_descr(const char **frame_descr,
 					      char *token, size_t max_tok_len,
mm/kasan/report_tags.c +5 -0
index 6ddb55676a7c..4060d0503462 100644
@@ -85,6 +85,11 @@ void *find_first_bad_addr(void *addr, size_t size)
 	return p;
 }
 
+void metadata_fetch_row(char *buffer, void *row)
+{
+	memcpy(buffer, kasan_mem_to_shadow(row), META_BYTES_PER_ROW);
+}
+
 void print_tags(u8 addr_tag, const void *addr)
 {
 	u8 *shadow = (u8 *)kasan_mem_to_shadow(addr);
Signature · 1 line
2.28.0.220.ged08abb693-goog
#21 lore raw

PATCH 19/35 kasan: don't allow SW_TAGS with ARM64_MTE

In reply to Andrey Konovalov

Software tag-based KASAN provides its own tag checking machinery that can conflict with MTE. Don't allow enabling software tag-based KASAN when MTE is enabled.

---
 lib/Kconfig.kasan | 1 +
 1 file changed, 1 insertion(+)
lib/Kconfig.kasan +1 -0
index b4cf6c519d71..e500c18cbe79 100644
@@ -69,6 +69,7 @@ config KASAN_GENERIC
 config KASAN_SW_TAGS
 	bool "Software tag-based mode"
 	depends on HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS
+	depends on !ARM64_MTE
 	help
 	  Enables software tag-based KASAN mode.
 
Signature · 1 line
2.28.0.220.ged08abb693-goog
maintainer
#22 lore raw

Re: [PATCH 19/35] kasan: don't allow SW_TAGS with ARM64_MTE

Quoted 14 lines · Andrey Konovalov

Software tag-based KASAN provides its own tag checking machinery that can conflict with MTE. Don't allow enabling software tag-based KASAN when MTE is enabled.

---
 lib/Kconfig.kasan | 1 +
 1 file changed, 1 insertion(+)
lib/Kconfig.kasan +0 -0
index b4cf6c519d71..e500c18cbe79 100644

lib/Kconfig.kasan config KASAN_GENERIC · line 72

Quoted 4 lines
lib/Kconfig.kasan +1 -0
@@ -69,6 +69,7 @@ config KASAN_GENERIC
 config KASAN_SW_TAGS
 	bool "Software tag-based mode"
 	depends on HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS
+	depends on !ARM64_MTE

I think that's better as:

arch/arm64/Kconfig +1 -1
index 10cf81d70657..736c32bd8905 100644
@@ -131,7 +131,7 @@ config ARM64
 	select HAVE_ARCH_JUMP_LABEL
 	select HAVE_ARCH_JUMP_LABEL_RELATIVE
 	select HAVE_ARCH_KASAN if !(ARM64_16K_PAGES && ARM64_VA_BITS_48)
-	select HAVE_ARCH_KASAN_SW_TAGS if HAVE_ARCH_KASAN
+	select HAVE_ARCH_KASAN_SW_TAGS if HAVE_ARCH_KASAN && !ARM64_MTE
 	select HAVE_ARCH_KGDB
 	select HAVE_ARCH_MMAP_RND_BITS
 	select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
Signature · 1 line
Catalin
#23 lore raw

Re: [PATCH 19/35] kasan: don't allow SW_TAGS with ARM64_MTE

Hi Andrey,

Quoted 28 lines · Catalin Marinas
Quoted 14 lines · Andrey Konovalov

Software tag-based KASAN provides its own tag checking machinery that can conflict with MTE. Don't allow enabling software tag-based KASAN when MTE is enabled.

---
 lib/Kconfig.kasan | 1 +
 1 file changed, 1 insertion(+)
lib/Kconfig.kasan +0 -0
index b4cf6c519d71..e500c18cbe79 100644

lib/Kconfig.kasan config KASAN_GENERIC · line 72

Quoted 4 lines
lib/Kconfig.kasan +1 -0
@@ -69,6 +69,7 @@ config KASAN_GENERIC
 config KASAN_SW_TAGS
 	bool "Software tag-based mode"
 	depends on HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS
+	depends on !ARM64_MTE

I think that's better as:

arch/arm64/Kconfig +0 -0
index 10cf81d70657..736c32bd8905 100644

arch/arm64/Kconfig config ARM64 · line 137

Quoted 8 lines
arch/arm64/Kconfig +1 -1
@@ -131,7 +131,7 @@ config ARM64
 	select HAVE_ARCH_JUMP_LABEL
 	select HAVE_ARCH_JUMP_LABEL_RELATIVE
 	select HAVE_ARCH_KASAN if !(ARM64_16K_PAGES && ARM64_VA_BITS_48)
-	select HAVE_ARCH_KASAN_SW_TAGS if HAVE_ARCH_KASAN
+	select HAVE_ARCH_KASAN_SW_TAGS if HAVE_ARCH_KASAN && !ARM64_MTE
 	select HAVE_ARCH_KGDB
 	select HAVE_ARCH_MMAP_RND_BITS
 	select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT

I agree with Catalin here, "select HAVE_ARCH_KASAN_SW_TAGS if HAVE_ARCH_KASAN && !ARM64_MTE" should be sufficient.

Signature · 2 lines
Regards,
Vincenzo
#24 lore raw

Re: [PATCH 19/35] kasan: don't allow SW_TAGS with ARM64_MTE

Quoted 35 lines · Vincenzo Frascino

Hi Andrey,

Quoted 31 lines · Catalin Marinas
Quoted 14 lines · Andrey Konovalov

Software tag-based KASAN provides its own tag checking machinery that can conflict with MTE. Don't allow enabling software tag-based KASAN when MTE is enabled.

---
 lib/Kconfig.kasan | 1 +
 1 file changed, 1 insertion(+)
lib/Kconfig.kasan +0 -0
index b4cf6c519d71..e500c18cbe79 100644

lib/Kconfig.kasan config KASAN_GENERIC · line 72

Quoted 4 lines
lib/Kconfig.kasan +1 -0
@@ -69,6 +69,7 @@ config KASAN_GENERIC
 config KASAN_SW_TAGS
     bool "Software tag-based mode"
     depends on HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS
+    depends on !ARM64_MTE

I think that's better as:

arch/arm64/Kconfig +0 -1
index 10cf81d70657..736c32bd8905 100644
@@ -131,7 +131,7 @@ config ARM64
      select HAVE_ARCH_JUMP_LABEL
      select HAVE_ARCH_JUMP_LABEL_RELATIVE
      select HAVE_ARCH_KASAN if !(ARM64_16K_PAGES && ARM64_VA_BITS_48)
-     select HAVE_ARCH_KASAN_SW_TAGS if HAVE_ARCH_KASAN
Quoted 8 lines

arch/arm64/Kconfig config ARM64 · line 137

Quoted 5 lines
arch/arm64/Kconfig +1 -0
+     select HAVE_ARCH_KASAN_SW_TAGS if HAVE_ARCH_KASAN && !ARM64_MTE
      select HAVE_ARCH_KGDB
      select HAVE_ARCH_MMAP_RND_BITS
      select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT

I agree with Catalin here, "select HAVE_ARCH_KASAN_SW_TAGS if HAVE_ARCH_KASAN && !ARM64_MTE" should be sufficient.

Sounds good, will do in v2, thanks!

#25 lore raw

PATCH 20/35 arm64: mte: Add in-kernel MTE helpers

In reply to Andrey Konovalov

From: Vincenzo Frascino <[email protected]>

Provide helper functions to manipulate allocation and pointer tags for kernel addresses.

Low-level helper functions (mte_assign_*, written in assembly) operate tag values from the [0x0, 0xF] range. High-level helper functions (mte_get/set_*) use the [0xF0, 0xFF] range to preserve compatibility with normal kernel pointers that have 0xFF in their top byte.

MTE_GRANULE_SIZE definition is moved to mte_asm.h header that doesn't have any dependencies and is safe to include into any low-level header.

---
 arch/arm64/include/asm/esr.h     |  1 +
 arch/arm64/include/asm/mte.h     | 46 +++++++++++++++++++++++++++++---
 arch/arm64/include/asm/mte_asm.h | 10 +++++++
 arch/arm64/kernel/mte.c          | 43 +++++++++++++++++++++++++++++
 arch/arm64/lib/mte.S             | 41 ++++++++++++++++++++++++++++
 5 files changed, 138 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm64/include/asm/mte_asm.h
arch/arm64/include/asm/esr.h +1 -0
index 035003acfa87..bc0dc66a6a27 100644
@@ -103,6 +103,7 @@
 #define ESR_ELx_FSC		(0x3F)
 #define ESR_ELx_FSC_TYPE	(0x3C)
 #define ESR_ELx_FSC_EXTABT	(0x10)
+#define ESR_ELx_FSC_MTE		(0x11)
 #define ESR_ELx_FSC_SERROR	(0x11)
 #define ESR_ELx_FSC_ACCESS	(0x08)
 #define ESR_ELx_FSC_FAULT	(0x04)
arch/arm64/include/asm/mte.h +43 -3

71 lines not on this page · raw message

arch/arm64/include/asm/mte_asm.h new file +10 -0
new file mode 100644
index 000000000000..aa532c1851e1
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020 ARM Ltd.
+ */
+#ifndef __ASM_MTE_ASM_H
+#define __ASM_MTE_ASM_H
+
+#define MTE_GRANULE_SIZE	UL(16)
+
+#endif /* __ASM_MTE_ASM_H  */
arch/arm64/kernel/mte.c +43 -0

57 lines not on this page · raw message

arch/arm64/lib/mte.S +41 -0

44 lines not on this page · raw message

Signature · 1 line
2.28.0.220.ged08abb693-goog
maintainer
#26 lore raw

Re: [PATCH 20/35] arm64: mte: Add in-kernel MTE helpers

arch/arm64/include/asm/mte.h line 8

Quoted 10 lines · Andrey Konovalov
arch/arm64/include/asm/mte.h +1 -1
index 1c99fcadb58c..733be1cb5c95 100644
@@ -5,14 +5,19 @@
 #ifndef __ASM_MTE_H
 #define __ASM_MTE_H
 
-#define MTE_GRANULE_SIZE	UL(16)
+#include <asm/mte_asm.h>

So the reason for this move is to include it in asm/cache.h. Fine by me but...

arch/arm64/include/asm/mte.h line 14

Quoted 5 lines
arch/arm64/include/asm/mte.h +2 -0
 #define MTE_GRANULE_MASK	(~(MTE_GRANULE_SIZE - 1))
 #define MTE_TAG_SHIFT		56
 #define MTE_TAG_SIZE		4
+#define MTE_TAG_MASK		GENMASK((MTE_TAG_SHIFT + (MTE_TAG_SIZE - 1)), MTE_TAG_SHIFT)
+#define MTE_TAG_MAX		(MTE_TAG_MASK >> MTE_TAG_SHIFT)

... I'd rather move all these definitions in a file with a more meaningful name like mte-def.h. The _asm implies being meant for .S files inclusion which isn't the case.

arch/arm64/kernel/mte.c int memcmp_pages(struct page *page1, struct page *page2) · line 80

Quoted 12 lines
arch/arm64/kernel/mte.c +4 -0
index eb39504e390a..e2d708b4583d 100644
@@ -72,6 +74,47 @@ int memcmp_pages(struct page *page1, struct page *page2)
 	return ret;
 }
 
+u8 mte_get_mem_tag(void *addr)
+{
+	if (system_supports_mte())
+		addr = mte_assign_valid_ptr_tag(addr);

The mte_assign_valid_ptr_tag() is slightly misleading. All it does is read the allocation tag from memory.

I also think this should be inline asm, possibly using alternatives. It's just an LDG instruction (and it saves us from having to invent a better function name).

arch/arm64/kernel/mte.c int memcmp_pages(struct page *page1, struct page *page2) · line 90

Quoted 10 lines
arch/arm64/kernel/mte.c +10 -0
+
+	return 0xF0 | mte_get_ptr_tag(addr);
+}
+
+u8 mte_get_random_tag(void)
+{
+	u8 tag = 0xF;
+
+	if (system_supports_mte())
+		tag = mte_get_ptr_tag(mte_assign_random_ptr_tag(NULL));

Another alternative inline asm with an IRG instruction.

Quoted 4 lines
arch/arm64/kernel/mte.c +4 -0
+
+	return 0xF0 | tag;
+}
+

arch/arm64/kernel/mte.c int memcmp_pages(struct page *page1, struct page *page2) · line 104

Quoted 10 lines
arch/arm64/kernel/mte.c +10 -0
+void * __must_check mte_set_mem_tag_range(void *addr, size_t size, u8 tag)
+{
+	void *ptr = addr;
+
+	if ((!system_supports_mte()) || (size == 0))
+		return addr;
+
+	tag = 0xF0 | (tag & 0xF);
+	ptr = (void *)__tag_set(ptr, tag);
+	size = ALIGN(size, MTE_GRANULE_SIZE);

I think aligning the size is dangerous. Can we instead turn it into a WARN_ON if not already aligned? At a quick look, the callers of kasan_{un,}poison_memory() already align the size.

arch/arm64/kernel/mte.c int memcmp_pages(struct page *page1, struct page *page2) · line 115

Quoted 11 lines
arch/arm64/kernel/mte.c +11 -0
+
+	mte_assign_mem_tag_range(ptr, size);
+
+	/*
+	 * mte_assign_mem_tag_range() can be invoked in a multi-threaded
+	 * context, ensure that tags are written in memory before the
+	 * reference is used.
+	 */
+	smp_wmb();
+
+	return ptr;

I'm not sure I understand the barrier here. It ensures the relative ordering of memory (or tag) accesses on a CPU as observed by other CPUs. While the first access here is setting the tag, I can't see what other access on _this_ CPU it is ordered with.

Quoted 25 lines
arch/arm64/kernel/mte.c +2 -0
+}
+
 static void update_sctlr_el1_tcf0(u64 tcf0)
 {
 	/* ISB required for the kernel uaccess routines */
arch/arm64/lib/mte.S +12 -0
index 03ca6d8b8670..8c743540e32c 100644
@@ -149,3 +149,44 @@ SYM_FUNC_START(mte_restore_page_tags)
 
 	ret
 SYM_FUNC_END(mte_restore_page_tags)
+
+/*
+ * Assign pointer tag based on the allocation tag
+ *   x0 - source pointer
+ * Returns:
+ *   x0 - pointer with the correct tag to access memory
+ */
+SYM_FUNC_START(mte_assign_valid_ptr_tag)
+	ldg	x0, [x0]
+	ret
+SYM_FUNC_END(mte_assign_valid_ptr_tag)
+

arch/arm64/lib/mte.S SYM_FUNC_START(mte_restore_page_tags) · line 173

Quoted 10 lines
arch/arm64/lib/mte.S +10 -0
+/*
+ * Assign random pointer tag
+ *   x0 - source pointer
+ * Returns:
+ *   x0 - pointer with a random tag
+ */
+SYM_FUNC_START(mte_assign_random_ptr_tag)
+	irg	x0, x0
+	ret
+SYM_FUNC_END(mte_assign_random_ptr_tag)

As I said above, these two can be inline asm.

arch/arm64/lib/mte.S SYM_FUNC_START(mte_restore_page_tags) · line 185

Quoted 12 lines
arch/arm64/lib/mte.S +12 -0
+
+/*
+ * Assign allocation tags for a region of memory based on the pointer tag
+ *   x0 - source pointer
+ *   x1 - size
+ *
+ * Note: size is expected to be MTE_GRANULE_SIZE aligned
+ */
+SYM_FUNC_START(mte_assign_mem_tag_range)
+	/* if (src == NULL) return; */
+	cbz	x0, 2f
+	/* if (size == 0) return; */

You could skip the cbz here and just document that the size should be non-zero and aligned. The caller already takes care of this check.

Quoted 7 lines
arch/arm64/lib/mte.S +7 -0
+	cbz	x1, 2f
+1:	stg	x0, [x0]
+	add	x0, x0, #MTE_GRANULE_SIZE
+	sub	x1, x1, #MTE_GRANULE_SIZE
+	cbnz	x1, 1b
+2:	ret
+SYM_FUNC_END(mte_assign_mem_tag_range)
Signature · 1 line
Catalin
#27 lore raw

Re: [PATCH 20/35] arm64: mte: Add in-kernel MTE helpers

Hi Catalin,

Quoted 15 lines · Catalin Marinas

arch/arm64/include/asm/mte.h line 8

Quoted 10 lines · Andrey Konovalov
arch/arm64/include/asm/mte.h +1 -1
index 1c99fcadb58c..733be1cb5c95 100644
@@ -5,14 +5,19 @@
 #ifndef __ASM_MTE_H
 #define __ASM_MTE_H
 
-#define MTE_GRANULE_SIZE	UL(16)
+#include <asm/mte_asm.h>

So the reason for this move is to include it in asm/cache.h. Fine by me but...

Quoted 10 lines

arch/arm64/include/asm/mte.h line 14

Quoted 5 lines
arch/arm64/include/asm/mte.h +2 -0
 #define MTE_GRANULE_MASK	(~(MTE_GRANULE_SIZE - 1))
 #define MTE_TAG_SHIFT		56
 #define MTE_TAG_SIZE		4
+#define MTE_TAG_MASK		GENMASK((MTE_TAG_SHIFT + (MTE_TAG_SIZE - 1)), MTE_TAG_SHIFT)
+#define MTE_TAG_MAX		(MTE_TAG_MASK >> MTE_TAG_SHIFT)

... I'd rather move all these definitions in a file with a more meaningful name like mte-def.h. The _asm implies being meant for .S files inclusion which isn't the case.

mte-asm.h was originally called mte_helper.h hence it made sense to have these defines here. But I agree with your proposal it makes things more readable and it is in line with the rest of the arm64 code (e.g. page-def.h).

We should as well update the commit message accordingly.

Quoted 16 lines

arch/arm64/kernel/mte.c int memcmp_pages(struct page *page1, struct page *page2) · line 80

Quoted 12 lines
arch/arm64/kernel/mte.c +4 -0
index eb39504e390a..e2d708b4583d 100644
@@ -72,6 +74,47 @@ int memcmp_pages(struct page *page1, struct page *page2)
 	return ret;
 }
 
+u8 mte_get_mem_tag(void *addr)
+{
+	if (system_supports_mte())
+		addr = mte_assign_valid_ptr_tag(addr);

The mte_assign_valid_ptr_tag() is slightly misleading. All it does is read the allocation tag from memory.

Quoted 4 lines

I also think this should be inline asm, possibly using alternatives. It's just an LDG instruction (and it saves us from having to invent a better function name).

Yes, I agree, I implemented this code in the early days and never got around to refactor it.

Quoted 4 lines
Quoted 4 lines
arch/arm64/kernel/mte.c +4 -0
+
+	return 0xF0 | mte_get_ptr_tag(addr);
+}
+
Quoted 9 lines

arch/arm64/kernel/mte.c int memcmp_pages(struct page *page1, struct page *page2) · line 90

Quoted 6 lines
arch/arm64/kernel/mte.c +6 -0
+u8 mte_get_random_tag(void)
+{
+	u8 tag = 0xF;
+
+	if (system_supports_mte())
+		tag = mte_get_ptr_tag(mte_assign_random_ptr_tag(NULL));

Another alternative inline asm with an IRG instruction.

As per above.

Quoted 10 lines
Quoted 10 lines
arch/arm64/kernel/mte.c +10 -0
+
+	return 0xF0 | tag;
+}
+
+void * __must_check mte_set_mem_tag_range(void *addr, size_t size, u8 tag)
+{
+	void *ptr = addr;
+
+	if ((!system_supports_mte()) || (size == 0))
+		return addr;
Quoted 9 lines

arch/arm64/kernel/mte.c int memcmp_pages(struct page *page1, struct page *page2) · line 104

Quoted 4 lines
arch/arm64/kernel/mte.c +4 -0
+
+	tag = 0xF0 | (tag & 0xF);
+	ptr = (void *)__tag_set(ptr, tag);
+	size = ALIGN(size, MTE_GRANULE_SIZE);

I think aligning the size is dangerous. Can we instead turn it into a WARN_ON if not already aligned? At a quick look, the callers of kasan_{un,}poison_memory() already align the size.

The size here is used only for tagging purposes and if we want to tag a subgranule amount of memory we end up tagging the granule anyway. Why do you think it can be dangerous?

Anyway I agree on the fact that is seems redundant, a WARN_ON here should be sufficient.

Quoted 8 lines
Quoted 8 lines
arch/arm64/kernel/mte.c +8 -0
+
+	mte_assign_mem_tag_range(ptr, size);
+
+	/*
+	 * mte_assign_mem_tag_range() can be invoked in a multi-threaded
+	 * context, ensure that tags are written in memory before the
+	 * reference is used.
+	 */
Quoted 9 lines

arch/arm64/kernel/mte.c int memcmp_pages(struct page *page1, struct page *page2) · line 115

Quoted 3 lines
arch/arm64/kernel/mte.c +3 -0
+	smp_wmb();
+
+	return ptr;

I'm not sure I understand the barrier here. It ensures the relative ordering of memory (or tag) accesses on a CPU as observed by other CPUs. While the first access here is setting the tag, I can't see what other access on _this_ CPU it is ordered with.

You are right it can be removed. I was just overthinking here.

Quoted 29 lines
Quoted 29 lines
arch/arm64/kernel/mte.c +2 -0
+}
+
 static void update_sctlr_el1_tcf0(u64 tcf0)
 {
 	/* ISB required for the kernel uaccess routines */
arch/arm64/lib/mte.S +16 -0
index 03ca6d8b8670..8c743540e32c 100644
@@ -149,3 +149,44 @@ SYM_FUNC_START(mte_restore_page_tags)
 
 	ret
 SYM_FUNC_END(mte_restore_page_tags)
+
+/*
+ * Assign pointer tag based on the allocation tag
+ *   x0 - source pointer
+ * Returns:
+ *   x0 - pointer with the correct tag to access memory
+ */
+SYM_FUNC_START(mte_assign_valid_ptr_tag)
+	ldg	x0, [x0]
+	ret
+SYM_FUNC_END(mte_assign_valid_ptr_tag)
+
+/*
+ * Assign random pointer tag
+ *   x0 - source pointer
+ * Returns:
Quoted 9 lines

arch/arm64/lib/mte.S SYM_FUNC_START(mte_restore_page_tags) · line 173

Quoted 6 lines
arch/arm64/lib/mte.S +6 -0
+ *   x0 - pointer with a random tag
+ */
+SYM_FUNC_START(mte_assign_random_ptr_tag)
+	irg	x0, x0
+	ret
+SYM_FUNC_END(mte_assign_random_ptr_tag)

As I said above, these two can be inline asm.

Agreed.

Quoted 7 lines
Quoted 7 lines
arch/arm64/lib/mte.S +7 -0
+
+/*
+ * Assign allocation tags for a region of memory based on the pointer tag
+ *   x0 - source pointer
+ *   x1 - size
+ *
+ * Note: size is expected to be MTE_GRANULE_SIZE aligned
Quoted 9 lines

arch/arm64/lib/mte.S SYM_FUNC_START(mte_restore_page_tags) · line 185

Quoted 5 lines
arch/arm64/lib/mte.S +5 -0
+ */
+SYM_FUNC_START(mte_assign_mem_tag_range)
+	/* if (src == NULL) return; */
+	cbz	x0, 2f
+	/* if (size == 0) return; */

You could skip the cbz here and just document that the size should be non-zero and aligned. The caller already takes care of this check.

I would prefer to keep the check here, unless there is a valid reason, since allocate(0) is a viable option hence tag(x, 0) should be as well. The caller takes care of it in one place, today, but I do not know where the API will be used in future.

Quoted 8 lines
Quoted 7 lines
arch/arm64/lib/mte.S +7 -0
+	cbz	x1, 2f
+1:	stg	x0, [x0]
+	add	x0, x0, #MTE_GRANULE_SIZE
+	sub	x1, x1, #MTE_GRANULE_SIZE
+	cbnz	x1, 1b
+2:	ret
+SYM_FUNC_END(mte_assign_mem_tag_range)
Signature · 2 lines
Regards,
Vincenzo
maintainer
#28 lore raw

Re: [PATCH 20/35] arm64: mte: Add in-kernel MTE helpers

Quoted 17 lines · Vincenzo Frascino
Quoted 15 lines · Catalin Marinas

arch/arm64/kernel/mte.c int memcmp_pages(struct page *page1, struct page *page2) · line 104

Quoted 10 lines · Andrey Konovalov
arch/arm64/kernel/mte.c +10 -0
+void * __must_check mte_set_mem_tag_range(void *addr, size_t size, u8 tag)
+{
+	void *ptr = addr;
+
+	if ((!system_supports_mte()) || (size == 0))
+		return addr;
+
+	tag = 0xF0 | (tag & 0xF);
+	ptr = (void *)__tag_set(ptr, tag);
+	size = ALIGN(size, MTE_GRANULE_SIZE);

I think aligning the size is dangerous. Can we instead turn it into a WARN_ON if not already aligned? At a quick look, the callers of kasan_{un,}poison_memory() already align the size.

Quoted 3 lines

The size here is used only for tagging purposes and if we want to tag a subgranule amount of memory we end up tagging the granule anyway. Why do you think it can be dangerous?

In principle, I don't like expanding the size unless you are an allocator. Since this code doesn't control the placement of the object it was given, a warn seems more appropriate.

Quoted 15 lines
Quoted 6 lines
Quoted 6 lines

+/*
+ * Assign allocation tags for a region of memory based on the pointer tag
+ * x0 - source pointer
+ * x1 - size
+ *
+ * Note: size is expected to be MTE_GRANULE_SIZE aligned

Quoted 8 lines

arch/arm64/lib/mte.S SYM_FUNC_START(mte_restore_page_tags) · line 185

Quoted 5 lines

+ */

arch/arm64/lib/mte.S +4 -0
+SYM_FUNC_START(mte_assign_mem_tag_range)
+	/* if (src == NULL) return; */
+	cbz	x0, 2f
+	/* if (size == 0) return; */

You could skip the cbz here and just document that the size should be non-zero and aligned. The caller already takes care of this check.

Quoted 4 lines

I would prefer to keep the check here, unless there is a valid reason, since allocate(0) is a viable option hence tag(x, 0) should be as well. The caller takes care of it in one place, today, but I do not know where the API will be used in future.

That's why I said just document it in the comment above the function.

The check is also insufficient if the size is not aligned to an MTE granule, so it's not really consistent. This function should end with a subs followed by b.gt as cbnz will get stuck in a loop for unaligned size.

Signature · 1 line
Catalin
#29 lore raw

Re: [PATCH 20/35] arm64: mte: Add in-kernel MTE helpers

Quoted 18 lines · Catalin Marinas
Quoted 17 lines · Vincenzo Frascino
Quoted 15 lines · Catalin Marinas

arch/arm64/kernel/mte.c int memcmp_pages(struct page *page1, struct page *page2) · line 104

Quoted 10 lines · Andrey Konovalov
arch/arm64/kernel/mte.c +10 -0
+void * __must_check mte_set_mem_tag_range(void *addr, size_t size, u8 tag)
+{
+	void *ptr = addr;
+
+	if ((!system_supports_mte()) || (size == 0))
+		return addr;
+
+	tag = 0xF0 | (tag & 0xF);
+	ptr = (void *)__tag_set(ptr, tag);
+	size = ALIGN(size, MTE_GRANULE_SIZE);

I think aligning the size is dangerous. Can we instead turn it into a WARN_ON if not already aligned? At a quick look, the callers of kasan_{un,}poison_memory() already align the size.

Quoted 8 lines
Quoted 3 lines

The size here is used only for tagging purposes and if we want to tag a subgranule amount of memory we end up tagging the granule anyway. Why do you think it can be dangerous?

In principle, I don't like expanding the size unless you are an allocator. Since this code doesn't control the placement of the object it was given, a warn seems more appropriate.

That's a good point. Ok, we can change this in a warning.

Quoted 20 lines
Quoted 15 lines
Quoted 6 lines
Quoted 6 lines

+/*
+ * Assign allocation tags for a region of memory based on the pointer tag
+ * x0 - source pointer
+ * x1 - size
+ *
+ * Note: size is expected to be MTE_GRANULE_SIZE aligned

Quoted 8 lines

arch/arm64/lib/mte.S SYM_FUNC_START(mte_restore_page_tags) · line 185

Quoted 5 lines

+ */

arch/arm64/lib/mte.S +4 -0
+SYM_FUNC_START(mte_assign_mem_tag_range)
+	/* if (src == NULL) return; */
+	cbz	x0, 2f
+	/* if (size == 0) return; */

You could skip the cbz here and just document that the size should be non-zero and aligned. The caller already takes care of this check.

Quoted 4 lines

I would prefer to keep the check here, unless there is a valid reason, since allocate(0) is a viable option hence tag(x, 0) should be as well. The caller takes care of it in one place, today, but I do not know where the API will be used in future.

Quoted 7 lines

That's why I said just document it in the comment above the function.

The check is also insufficient if the size is not aligned to an MTE granule, so it's not really consistent. This function should end with a subs followed by b.gt as cbnz will get stuck in a loop for unaligned size.

That's correct. Thanks for pointing this out. I currently used it only in places where the caller took care to align the size. But in future we cannot know hence we should harden the function with what you are suggesting.

Signature · 2 lines
Regards,
Vincenzo
#30 lore raw

Re: [PATCH 20/35] arm64: mte: Add in-kernel MTE helpers

In reply to Catalin Marinas
Quoted 16 lines · Catalin Marinas

arch/arm64/include/asm/mte.h line 8

Quoted 10 lines · Andrey Konovalov
arch/arm64/include/asm/mte.h +1 -1
index 1c99fcadb58c..733be1cb5c95 100644
@@ -5,14 +5,19 @@
 #ifndef __ASM_MTE_H
 #define __ASM_MTE_H
 
-#define MTE_GRANULE_SIZE     UL(16)
+#include <asm/mte_asm.h>

So the reason for this move is to include it in asm/cache.h. Fine by me but...

Quoted 9 lines

arch/arm64/include/asm/mte.h line 14

Quoted 5 lines
arch/arm64/include/asm/mte.h +2 -0
 #define MTE_GRANULE_MASK     (~(MTE_GRANULE_SIZE - 1))
 #define MTE_TAG_SHIFT                56
 #define MTE_TAG_SIZE         4
+#define MTE_TAG_MASK         GENMASK((MTE_TAG_SHIFT + (MTE_TAG_SIZE - 1)), MTE_TAG_SHIFT)
+#define MTE_TAG_MAX          (MTE_TAG_MASK >> MTE_TAG_SHIFT)

... I'd rather move all these definitions in a file with a more meaningful name like mte-def.h. The _asm implies being meant for .S files inclusion which isn't the case.

Sounds good, I'll leave fixing this and other arm64-specific comments to Vincenzo. I'll change KASAN code to use mte-def.h once I have patches where this file is renamed.

Quoted 139 lines

arch/arm64/kernel/mte.c int memcmp_pages(struct page *page1, struct page *page2) · line 80

Quoted 13 lines
arch/arm64/kernel/mte.c +4 -0
index eb39504e390a..e2d708b4583d 100644
@@ -72,6 +74,47 @@ int memcmp_pages(struct page *page1, struct page *page2)
      return ret;
 }
 
+u8 mte_get_mem_tag(void *addr)
+{
+     if (system_supports_mte())
+             addr = mte_assign_valid_ptr_tag(addr);

The mte_assign_valid_ptr_tag() is slightly misleading. All it does is read the allocation tag from memory.

I also think this should be inline asm, possibly using alternatives. It's just an LDG instruction (and it saves us from having to invent a better function name).

arch/arm64/kernel/mte.c int memcmp_pages(struct page *page1, struct page *page2) · line 90

Quoted 10 lines
arch/arm64/kernel/mte.c +10 -0
+
+     return 0xF0 | mte_get_ptr_tag(addr);
+}
+
+u8 mte_get_random_tag(void)
+{
+     u8 tag = 0xF;
+
+     if (system_supports_mte())
+             tag = mte_get_ptr_tag(mte_assign_random_ptr_tag(NULL));

Another alternative inline asm with an IRG instruction.

Quoted 4 lines
arch/arm64/kernel/mte.c +4 -0
+
+     return 0xF0 | tag;
+}
+

arch/arm64/kernel/mte.c int memcmp_pages(struct page *page1, struct page *page2) · line 104

Quoted 10 lines
arch/arm64/kernel/mte.c +10 -0
+void * __must_check mte_set_mem_tag_range(void *addr, size_t size, u8 tag)
+{
+     void *ptr = addr;
+
+     if ((!system_supports_mte()) || (size == 0))
+             return addr;
+
+     tag = 0xF0 | (tag & 0xF);
+     ptr = (void *)__tag_set(ptr, tag);
+     size = ALIGN(size, MTE_GRANULE_SIZE);

I think aligning the size is dangerous. Can we instead turn it into a WARN_ON if not already aligned? At a quick look, the callers of kasan_{un,}poison_memory() already align the size.

arch/arm64/kernel/mte.c int memcmp_pages(struct page *page1, struct page *page2) · line 115

Quoted 11 lines
arch/arm64/kernel/mte.c +11 -0
+
+     mte_assign_mem_tag_range(ptr, size);
+
+     /*
+      * mte_assign_mem_tag_range() can be invoked in a multi-threaded
+      * context, ensure that tags are written in memory before the
+      * reference is used.
+      */
+     smp_wmb();
+
+     return ptr;

I'm not sure I understand the barrier here. It ensures the relative ordering of memory (or tag) accesses on a CPU as observed by other CPUs. While the first access here is setting the tag, I can't see what other access on _this_ CPU it is ordered with.

Quoted 25 lines
arch/arm64/kernel/mte.c +2 -0
+}
+
 static void update_sctlr_el1_tcf0(u64 tcf0)
 {
      /* ISB required for the kernel uaccess routines */
arch/arm64/lib/mte.S +12 -0
index 03ca6d8b8670..8c743540e32c 100644
@@ -149,3 +149,44 @@ SYM_FUNC_START(mte_restore_page_tags)
 
      ret
 SYM_FUNC_END(mte_restore_page_tags)
+
+/*
+ * Assign pointer tag based on the allocation tag
+ *   x0 - source pointer
+ * Returns:
+ *   x0 - pointer with the correct tag to access memory
+ */
+SYM_FUNC_START(mte_assign_valid_ptr_tag)
+     ldg     x0, [x0]
+     ret
+SYM_FUNC_END(mte_assign_valid_ptr_tag)
+

arch/arm64/lib/mte.S SYM_FUNC_START(mte_restore_page_tags) · line 173

Quoted 10 lines
arch/arm64/lib/mte.S +10 -0
+/*
+ * Assign random pointer tag
+ *   x0 - source pointer
+ * Returns:
+ *   x0 - pointer with a random tag
+ */
+SYM_FUNC_START(mte_assign_random_ptr_tag)
+     irg     x0, x0
+     ret
+SYM_FUNC_END(mte_assign_random_ptr_tag)

As I said above, these two can be inline asm.

arch/arm64/lib/mte.S SYM_FUNC_START(mte_restore_page_tags) · line 185

Quoted 12 lines
arch/arm64/lib/mte.S +12 -0
+
+/*
+ * Assign allocation tags for a region of memory based on the pointer tag
+ *   x0 - source pointer
+ *   x1 - size
+ *
+ * Note: size is expected to be MTE_GRANULE_SIZE aligned
+ */
+SYM_FUNC_START(mte_assign_mem_tag_range)
+     /* if (src == NULL) return; */
+     cbz     x0, 2f
+     /* if (size == 0) return; */

You could skip the cbz here and just document that the size should be non-zero and aligned. The caller already takes care of this check.

arch/arm64/lib/mte.S SYM_FUNC_START(mte_restore_page_tags) · line 192

Quoted 7 lines
arch/arm64/lib/mte.S +7 -0
+     cbz     x1, 2f
+1:   stg     x0, [x0]
+     add     x0, x0, #MTE_GRANULE_SIZE
+     sub     x1, x1, #MTE_GRANULE_SIZE
+     cbnz    x1, 1b
+2:   ret
+SYM_FUNC_END(mte_assign_mem_tag_range)

--
Catalin

--
You received this message because you are subscribed to the Google Groups "kasan-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20200827093808.GB29264%40gaia.

#31 lore raw

Re: [PATCH 20/35] arm64: mte: Add in-kernel MTE helpers

In reply to Catalin Marinas
Quoted 42 lines · Catalin Marinas

arch/arm64/include/asm/mte.h line 8

Quoted 10 lines · Andrey Konovalov
arch/arm64/include/asm/mte.h +1 -1
index 1c99fcadb58c..733be1cb5c95 100644
@@ -5,14 +5,19 @@
 #ifndef __ASM_MTE_H
 #define __ASM_MTE_H
 
-#define MTE_GRANULE_SIZE     UL(16)
+#include <asm/mte_asm.h>

So the reason for this move is to include it in asm/cache.h. Fine by me but...

arch/arm64/include/asm/mte.h line 14

Quoted 5 lines
arch/arm64/include/asm/mte.h +2 -0
 #define MTE_GRANULE_MASK     (~(MTE_GRANULE_SIZE - 1))
 #define MTE_TAG_SHIFT                56
 #define MTE_TAG_SIZE         4
+#define MTE_TAG_MASK         GENMASK((MTE_TAG_SHIFT + (MTE_TAG_SIZE - 1)), MTE_TAG_SHIFT)
+#define MTE_TAG_MAX          (MTE_TAG_MASK >> MTE_TAG_SHIFT)

... I'd rather move all these definitions in a file with a more meaningful name like mte-def.h. The _asm implies being meant for .S files inclusion which isn't the case.

arch/arm64/kernel/mte.c int memcmp_pages(struct page *page1, struct page *page2) · line 80

Quoted 12 lines
arch/arm64/kernel/mte.c +4 -0
index eb39504e390a..e2d708b4583d 100644
@@ -72,6 +74,47 @@ int memcmp_pages(struct page *page1, struct page *page2)
      return ret;
 }
 
+u8 mte_get_mem_tag(void *addr)
+{
+     if (system_supports_mte())
+             addr = mte_assign_valid_ptr_tag(addr);

The mte_assign_valid_ptr_tag() is slightly misleading. All it does is read the allocation tag from memory.

Quoted 3 lines

I also think this should be inline asm, possibly using alternatives. It's just an LDG instruction (and it saves us from having to invent a better function name).

Could you point me to an example of inline asm with alternatives if there's any? I see alternative_if and other similar macros used in arch/arm64/ code, is that what you mean? Those seem to always use static conditions, like config values, but here we have a dynamic system_supports_mte(). Could you elaborate on how I should implement this?

maintainer
#32 lore raw

Re: [PATCH 20/35] arm64: mte: Add in-kernel MTE helpers

Quoted 47 lines · Andrey Konovalov
Quoted 41 lines · Catalin Marinas

arch/arm64/include/asm/mte.h line 8

Quoted 10 lines · Andrey Konovalov
arch/arm64/include/asm/mte.h +1 -1
index 1c99fcadb58c..733be1cb5c95 100644
@@ -5,14 +5,19 @@
 #ifndef __ASM_MTE_H
 #define __ASM_MTE_H
 
-#define MTE_GRANULE_SIZE     UL(16)
+#include <asm/mte_asm.h>

So the reason for this move is to include it in asm/cache.h. Fine by me but...

arch/arm64/include/asm/mte.h line 14

Quoted 5 lines
arch/arm64/include/asm/mte.h +2 -0
 #define MTE_GRANULE_MASK     (~(MTE_GRANULE_SIZE - 1))
 #define MTE_TAG_SHIFT                56
 #define MTE_TAG_SIZE         4
+#define MTE_TAG_MASK         GENMASK((MTE_TAG_SHIFT + (MTE_TAG_SIZE - 1)), MTE_TAG_SHIFT)
+#define MTE_TAG_MAX          (MTE_TAG_MASK >> MTE_TAG_SHIFT)

... I'd rather move all these definitions in a file with a more meaningful name like mte-def.h. The _asm implies being meant for .S files inclusion which isn't the case.

arch/arm64/kernel/mte.c int memcmp_pages(struct page *page1, struct page *page2) · line 80

Quoted 12 lines
arch/arm64/kernel/mte.c +4 -0
index eb39504e390a..e2d708b4583d 100644
@@ -72,6 +74,47 @@ int memcmp_pages(struct page *page1, struct page *page2)
      return ret;
 }
 
+u8 mte_get_mem_tag(void *addr)
+{
+     if (system_supports_mte())
+             addr = mte_assign_valid_ptr_tag(addr);

The mte_assign_valid_ptr_tag() is slightly misleading. All it does is read the allocation tag from memory.

Quoted 3 lines

I also think this should be inline asm, possibly using alternatives. It's just an LDG instruction (and it saves us from having to invent a better function name).

Quoted 6 lines

Could you point me to an example of inline asm with alternatives if there's any? I see alternative_if and other similar macros used in arch/arm64/ code, is that what you mean? Those seem to always use static conditions, like config values, but here we have a dynamic system_supports_mte(). Could you elaborate on how I should implement this?

There are plenty of ALTERNATIVE macro uses under arch/arm64, see arch/arm64/include/asm/alternative.h for the definition and some simple documentation.

In this case, something like (untested, haven't even checked whether it matches the mte_assign_valid_ptr_tag() code):

	asm(ALTERNATIVE("orr %0, %1, #0xff << 56", "ldg %0, [%1]", ARM64_HAS_MTE));
Signature · 1 line
Catalin
#33 lore raw

PATCH 21/35 arm64: mte: Add in-kernel tag fault handler

In reply to Andrey Konovalov

From: Vincenzo Frascino <[email protected]>

Add the implementation of the in-kernel fault handler.

When a tag fault happens on a kernel address:
* a warning is logged,
* the faulting instruction is skipped,
* the execution continues.

When a tag fault happens on a user address:
* the kernel executes do_bad_area() and panics.

---
 arch/arm64/mm/fault.c | 50 ++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 49 insertions(+), 1 deletion(-)
arch/arm64/mm/fault.c +49 -1
index 5e832b3387f1..c62c8ba85c0e 100644
@@ -33,6 +33,7 @@
 #include <asm/debug-monitors.h>
 #include <asm/esr.h>
 #include <asm/kprobes.h>
+#include <asm/mte.h>
 #include <asm/processor.h>
 #include <asm/sysreg.h>
 #include <asm/system_misc.h>
@@ -222,6 +223,20 @@ int ptep_set_access_flags(struct vm_area_struct *vma,
 	return 1;
 }
 
+static bool is_el1_mte_sync_tag_check_fault(unsigned int esr)
+{
+	unsigned int ec = ESR_ELx_EC(esr);
+	unsigned int fsc = esr & ESR_ELx_FSC;
+
+	if (ec != ESR_ELx_EC_DABT_CUR)
+		return false;
+
+	if (fsc == ESR_ELx_FSC_MTE)
+		return true;
+
+	return false;
+}
+
 static bool is_el1_instruction_abort(unsigned int esr)
 {
 	return ESR_ELx_EC(esr) == ESR_ELx_EC_IABT_CUR;
@@ -294,6 +309,18 @@ static void die_kernel_fault(const char *msg, unsigned long addr,
 	do_exit(SIGKILL);
 }
 
+static void report_tag_fault(unsigned long addr, unsigned int esr,
+			     struct pt_regs *regs)
+{
+	bool is_write = ((esr & ESR_ELx_WNR) >> ESR_ELx_WNR_SHIFT) != 0;
+
+	pr_alert("Memory Tagging Extension Fault in %pS\n", (void *)regs->pc);
+	pr_alert("  %s at address %lx\n", is_write ? "Write" : "Read", addr);
+	pr_alert("  Pointer tag: [%02x], memory tag: [%02x]\n",
+			mte_get_ptr_tag(addr),
+			mte_get_mem_tag((void *)addr));
+}
+
 static void __do_kernel_fault(unsigned long addr, unsigned int esr,
 			      struct pt_regs *regs)
 {
@@ -317,12 +344,16 @@ static void __do_kernel_fault(unsigned long addr, unsigned int esr,
 			msg = "execute from non-executable memory";
 		else
 			msg = "read from unreadable memory";
+	} else if (is_el1_mte_sync_tag_check_fault(esr)) {
+		report_tag_fault(addr, esr, regs);
+		msg = "memory tagging extension fault";
 	} else if (addr < PAGE_SIZE) {
 		msg = "NULL pointer dereference";
 	} else {
 		msg = "paging request";
 	}
 
+
 	die_kernel_fault(msg, addr, esr, regs);
 }
 
@@ -658,10 +689,27 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
 	return 0;
 }
 
+static int do_tag_recovery(unsigned long addr, unsigned int esr,
+			   struct pt_regs *regs)
+{
+	report_tag_fault(addr, esr, regs);
+
+	/* Skip over the faulting instruction and continue: */
+	arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE);
+
+	return 0;
+}
+
+
 static int do_tag_check_fault(unsigned long addr, unsigned int esr,
 			      struct pt_regs *regs)
 {
-	do_bad_area(addr, esr, regs);
+	/* The tag check fault (TCF) is per TTBR */
+	if (is_ttbr0_addr(addr))
+		do_bad_area(addr, esr, regs);
+	else
+		do_tag_recovery(addr, esr, regs);
+
 	return 0;
 }
 
Signature · 1 line
2.28.0.220.ged08abb693-goog
maintainer
#34 lore raw

Re: [PATCH 21/35] arm64: mte: Add in-kernel tag fault handler

Quoted 53 lines · Andrey Konovalov
arch/arm64/mm/fault.c +27 -0
index 5e832b3387f1..c62c8ba85c0e 100644
@@ -33,6 +33,7 @@
 #include <asm/debug-monitors.h>
 #include <asm/esr.h>
 #include <asm/kprobes.h>
+#include <asm/mte.h>
 #include <asm/processor.h>
 #include <asm/sysreg.h>
 #include <asm/system_misc.h>
@@ -222,6 +223,20 @@ int ptep_set_access_flags(struct vm_area_struct *vma,
 	return 1;
 }
 
+static bool is_el1_mte_sync_tag_check_fault(unsigned int esr)
+{
+	unsigned int ec = ESR_ELx_EC(esr);
+	unsigned int fsc = esr & ESR_ELx_FSC;
+
+	if (ec != ESR_ELx_EC_DABT_CUR)
+		return false;
+
+	if (fsc == ESR_ELx_FSC_MTE)
+		return true;
+
+	return false;
+}
+
 static bool is_el1_instruction_abort(unsigned int esr)
 {
 	return ESR_ELx_EC(esr) == ESR_ELx_EC_IABT_CUR;
@@ -294,6 +309,18 @@ static void die_kernel_fault(const char *msg, unsigned long addr,
 	do_exit(SIGKILL);
 }
 
+static void report_tag_fault(unsigned long addr, unsigned int esr,
+			     struct pt_regs *regs)
+{
+	bool is_write = ((esr & ESR_ELx_WNR) >> ESR_ELx_WNR_SHIFT) != 0;
+
+	pr_alert("Memory Tagging Extension Fault in %pS\n", (void *)regs->pc);
+	pr_alert("  %s at address %lx\n", is_write ? "Write" : "Read", addr);
+	pr_alert("  Pointer tag: [%02x], memory tag: [%02x]\n",
+			mte_get_ptr_tag(addr),
+			mte_get_mem_tag((void *)addr));
+}
+
 static void __do_kernel_fault(unsigned long addr, unsigned int esr,
 			      struct pt_regs *regs)
 {

arch/arm64/mm/fault.c static void __do_kernel_fault(unsigned long addr, unsigned int esr, · line 349

Quoted 6 lines
arch/arm64/mm/fault.c +3 -0
@@ -317,12 +344,16 @@ static void __do_kernel_fault(unsigned long addr, unsigned int esr,
 			msg = "execute from non-executable memory";
 		else
 			msg = "read from unreadable memory";
+	} else if (is_el1_mte_sync_tag_check_fault(esr)) {
+		report_tag_fault(addr, esr, regs);
+		msg = "memory tagging extension fault";

IIUC, that's dead code. See my comment below on do_tag_check_fault().

arch/arm64/mm/fault.c static void __do_kernel_fault(unsigned long addr, unsigned int esr, · line 356

Quoted 7 lines
arch/arm64/mm/fault.c +1 -0
 	} else if (addr < PAGE_SIZE) {
 		msg = "NULL pointer dereference";
 	} else {
 		msg = "paging request";
 	}
 
+

Unnecessary empty line.

Quoted 4 lines
arch/arm64/mm/fault.c +0 -0
 	die_kernel_fault(msg, addr, esr, regs);
 }
 

arch/arm64/mm/fault.c static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs) · line 698

Quoted 10 lines
arch/arm64/mm/fault.c +7 -0
@@ -658,10 +689,27 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
 	return 0;
 }
 
+static int do_tag_recovery(unsigned long addr, unsigned int esr,
+			   struct pt_regs *regs)
+{
+	report_tag_fault(addr, esr, regs);
+
+	/* Skip over the faulting instruction and continue: */
+	arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE);

Ooooh, do we expect the kernel to still behave correctly after this? I thought the recovery means disabling tag checking altogether and restarting the instruction rather than skipping over it. We only skip if we emulated it.

Quoted 4 lines
arch/arm64/mm/fault.c +4 -0
+
+	return 0;
+}
+

arch/arm64/mm/fault.c static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs) · line 711

Quoted 10 lines
arch/arm64/mm/fault.c +6 -1
+
 static int do_tag_check_fault(unsigned long addr, unsigned int esr,
 			      struct pt_regs *regs)
 {
-	do_bad_area(addr, esr, regs);
+	/* The tag check fault (TCF) is per TTBR */
+	if (is_ttbr0_addr(addr))
+		do_bad_area(addr, esr, regs);
+	else
+		do_tag_recovery(addr, esr, regs);

So we never invoke __do_kernel_fault() for a synchronous tag check in the kernel. What's with all the is_el1_mte_sync_tag_check_fault() check above?

Signature · 1 line
Catalin
#35 lore raw

Re: [PATCH 21/35] arm64: mte: Add in-kernel tag fault handler

Quoted 54 lines · Catalin Marinas
Quoted 53 lines · Andrey Konovalov
arch/arm64/mm/fault.c +27 -0
index 5e832b3387f1..c62c8ba85c0e 100644
@@ -33,6 +33,7 @@
 #include <asm/debug-monitors.h>
 #include <asm/esr.h>
 #include <asm/kprobes.h>
+#include <asm/mte.h>
 #include <asm/processor.h>
 #include <asm/sysreg.h>
 #include <asm/system_misc.h>
@@ -222,6 +223,20 @@ int ptep_set_access_flags(struct vm_area_struct *vma,
 	return 1;
 }
 
+static bool is_el1_mte_sync_tag_check_fault(unsigned int esr)
+{
+	unsigned int ec = ESR_ELx_EC(esr);
+	unsigned int fsc = esr & ESR_ELx_FSC;
+
+	if (ec != ESR_ELx_EC_DABT_CUR)
+		return false;
+
+	if (fsc == ESR_ELx_FSC_MTE)
+		return true;
+
+	return false;
+}
+
 static bool is_el1_instruction_abort(unsigned int esr)
 {
 	return ESR_ELx_EC(esr) == ESR_ELx_EC_IABT_CUR;
@@ -294,6 +309,18 @@ static void die_kernel_fault(const char *msg, unsigned long addr,
 	do_exit(SIGKILL);
 }
 
+static void report_tag_fault(unsigned long addr, unsigned int esr,
+			     struct pt_regs *regs)
+{
+	bool is_write = ((esr & ESR_ELx_WNR) >> ESR_ELx_WNR_SHIFT) != 0;
+
+	pr_alert("Memory Tagging Extension Fault in %pS\n", (void *)regs->pc);
+	pr_alert("  %s at address %lx\n", is_write ? "Write" : "Read", addr);
+	pr_alert("  Pointer tag: [%02x], memory tag: [%02x]\n",
+			mte_get_ptr_tag(addr),
+			mte_get_mem_tag((void *)addr));
+}
+
 static void __do_kernel_fault(unsigned long addr, unsigned int esr,
 			      struct pt_regs *regs)
 {
@@ -317,12 +344,16 @@ static void __do_kernel_fault(unsigned long addr, unsigned int esr,
Quoted 9 lines

arch/arm64/mm/fault.c static void __do_kernel_fault(unsigned long addr, unsigned int esr, · line 349

Quoted 6 lines
arch/arm64/mm/fault.c +3 -0
 			msg = "execute from non-executable memory";
 		else
 			msg = "read from unreadable memory";
+	} else if (is_el1_mte_sync_tag_check_fault(esr)) {
+		report_tag_fault(addr, esr, regs);
+		msg = "memory tagging extension fault";

IIUC, that's dead code. See my comment below on do_tag_check_fault().

That's correct. This was useful with "panic_on_mte_fault" kernel command line parameter. Since it has now been replaced by a similar kasan feature, this code can be safely removed.

Quoted 10 lines

arch/arm64/mm/fault.c static void __do_kernel_fault(unsigned long addr, unsigned int esr, · line 356

Quoted 7 lines
arch/arm64/mm/fault.c +1 -0
 	} else if (addr < PAGE_SIZE) {
 		msg = "NULL pointer dereference";
 	} else {
 		msg = "paging request";
 	}
 
+

Unnecessary empty line.

Agree.

Quoted 7 lines
Quoted 7 lines
arch/arm64/mm/fault.c +0 -0
 	die_kernel_fault(msg, addr, esr, regs);
 }
 
@@ -658,10 +689,27 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
 	return 0;
 }
 
Quoted 13 lines

arch/arm64/mm/fault.c static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs) · line 698

Quoted 7 lines
arch/arm64/mm/fault.c +7 -0
+static int do_tag_recovery(unsigned long addr, unsigned int esr,
+			   struct pt_regs *regs)
+{
+	report_tag_fault(addr, esr, regs);
+
+	/* Skip over the faulting instruction and continue: */
+	arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE);

Ooooh, do we expect the kernel to still behave correctly after this? I thought the recovery means disabling tag checking altogether and restarting the instruction rather than skipping over it. We only skip if we emulated it.

I tried to dig it out but I am not sure why we need this as well.

Quoted 10 lines
Quoted 10 lines
arch/arm64/mm/fault.c +6 -1
+
+	return 0;
+}
+
+
 static int do_tag_check_fault(unsigned long addr, unsigned int esr,
 			      struct pt_regs *regs)
 {
-	do_bad_area(addr, esr, regs);
+	/* The tag check fault (TCF) is per TTBR */
Quoted 9 lines

arch/arm64/mm/fault.c static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs) · line 711

Quoted 4 lines
arch/arm64/mm/fault.c +4 -0
+	if (is_ttbr0_addr(addr))
+		do_bad_area(addr, esr, regs);
+	else
+		do_tag_recovery(addr, esr, regs);

So we never invoke __do_kernel_fault() for a synchronous tag check in the kernel. What's with all the is_el1_mte_sync_tag_check_fault() check above?

That's correct. This had a meaning with "panic_on_mte_fault" but since the feature has been replaced is_el1_mte_sync_tag_check_fault() is not useful anymore.

Signature · 2 lines
Regards,
Vincenzo
#36 lore raw

Re: [PATCH 21/35] arm64: mte: Add in-kernel tag fault handler

In reply to Catalin Marinas
Quoted 81 lines · Catalin Marinas
Quoted 53 lines · Andrey Konovalov
arch/arm64/mm/fault.c +27 -0
index 5e832b3387f1..c62c8ba85c0e 100644
@@ -33,6 +33,7 @@
 #include <asm/debug-monitors.h>
 #include <asm/esr.h>
 #include <asm/kprobes.h>
+#include <asm/mte.h>
 #include <asm/processor.h>
 #include <asm/sysreg.h>
 #include <asm/system_misc.h>
@@ -222,6 +223,20 @@ int ptep_set_access_flags(struct vm_area_struct *vma,
      return 1;
 }
 
+static bool is_el1_mte_sync_tag_check_fault(unsigned int esr)
+{
+     unsigned int ec = ESR_ELx_EC(esr);
+     unsigned int fsc = esr & ESR_ELx_FSC;
+
+     if (ec != ESR_ELx_EC_DABT_CUR)
+             return false;
+
+     if (fsc == ESR_ELx_FSC_MTE)
+             return true;
+
+     return false;
+}
+
 static bool is_el1_instruction_abort(unsigned int esr)
 {
      return ESR_ELx_EC(esr) == ESR_ELx_EC_IABT_CUR;
@@ -294,6 +309,18 @@ static void die_kernel_fault(const char *msg, unsigned long addr,
      do_exit(SIGKILL);
 }
 
+static void report_tag_fault(unsigned long addr, unsigned int esr,
+                          struct pt_regs *regs)
+{
+     bool is_write = ((esr & ESR_ELx_WNR) >> ESR_ELx_WNR_SHIFT) != 0;
+
+     pr_alert("Memory Tagging Extension Fault in %pS\n", (void *)regs->pc);
+     pr_alert("  %s at address %lx\n", is_write ? "Write" : "Read", addr);
+     pr_alert("  Pointer tag: [%02x], memory tag: [%02x]\n",
+                     mte_get_ptr_tag(addr),
+                     mte_get_mem_tag((void *)addr));
+}
+
 static void __do_kernel_fault(unsigned long addr, unsigned int esr,
                            struct pt_regs *regs)
 {

arch/arm64/mm/fault.c static void __do_kernel_fault(unsigned long addr, unsigned int esr, · line 349

Quoted 6 lines
arch/arm64/mm/fault.c +3 -0
@@ -317,12 +344,16 @@ static void __do_kernel_fault(unsigned long addr, unsigned int esr,
                      msg = "execute from non-executable memory";
              else
                      msg = "read from unreadable memory";
+     } else if (is_el1_mte_sync_tag_check_fault(esr)) {
+             report_tag_fault(addr, esr, regs);
+             msg = "memory tagging extension fault";

IIUC, that's dead code. See my comment below on do_tag_check_fault().

arch/arm64/mm/fault.c static void __do_kernel_fault(unsigned long addr, unsigned int esr, · line 356

Quoted 7 lines
arch/arm64/mm/fault.c +1 -0
      } else if (addr < PAGE_SIZE) {
              msg = "NULL pointer dereference";
      } else {
              msg = "paging request";
      }
 
+

Unnecessary empty line.

Quoted 7 lines
arch/arm64/mm/fault.c +0 -0
      die_kernel_fault(msg, addr, esr, regs);
 }
 
@@ -658,10 +689,27 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
      return 0;
 }
 
Quoted 11 lines

arch/arm64/mm/fault.c static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs) · line 698

Quoted 7 lines
arch/arm64/mm/fault.c +7 -0
+static int do_tag_recovery(unsigned long addr, unsigned int esr,
+                        struct pt_regs *regs)
+{
+     report_tag_fault(addr, esr, regs);
+
+     /* Skip over the faulting instruction and continue: */
+     arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE);

Ooooh, do we expect the kernel to still behave correctly after this? I thought the recovery means disabling tag checking altogether and restarting the instruction rather than skipping over it.

The intention is to be able to catch multiple MTE faults without panicking or disabling MTE when executing KASAN tests (those do multiple bad accesses one after another). We do arm64_skip_faulting_instruction() for software tag-based KASAN too, it's not ideal, but works for testing purposes.

Can we disable MTE, reexecute the instruction, and then reenable MTE, or something like that?

When running in-kernel MTE in production, we'll either panic or disable MTE after the first fault. This was controlled by the panic_on_mte_fault option Vincenzo initially had.

Quoted 1 line

We only skip if we emulated it.

I'm not sure I understand this part, what do you mean by emulating?

Quoted 27 lines
Quoted 5 lines
arch/arm64/mm/fault.c +4 -0
+
+     return 0;
+}
+

arch/arm64/mm/fault.c static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs) · line 711

Quoted 10 lines
arch/arm64/mm/fault.c +6 -1
+
 static int do_tag_check_fault(unsigned long addr, unsigned int esr,
                            struct pt_regs *regs)
 {
-     do_bad_area(addr, esr, regs);
+     /* The tag check fault (TCF) is per TTBR */
+     if (is_ttbr0_addr(addr))
+             do_bad_area(addr, esr, regs);
+     else
+             do_tag_recovery(addr, esr, regs);

So we never invoke __do_kernel_fault() for a synchronous tag check in the kernel. What's with all the is_el1_mte_sync_tag_check_fault() check above?

--
Catalin

--
You received this message because you are subscribed to the Google Groups "kasan-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20200827095429.GC29264%40gaia.

maintainer
#37 lore raw

Re: [PATCH 21/35] arm64: mte: Add in-kernel tag fault handler

Quoted 15 lines · Andrey Konovalov
Quoted 12 lines · Catalin Marinas

arch/arm64/mm/fault.c static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs) · line 698

Quoted 7 lines · Andrey Konovalov
arch/arm64/mm/fault.c +7 -0
+static int do_tag_recovery(unsigned long addr, unsigned int esr,
+                        struct pt_regs *regs)
+{
+     report_tag_fault(addr, esr, regs);
+
+     /* Skip over the faulting instruction and continue: */
+     arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE);

Ooooh, do we expect the kernel to still behave correctly after this? I thought the recovery means disabling tag checking altogether and restarting the instruction rather than skipping over it.

Quoted 3 lines

The intention is to be able to catch multiple MTE faults without panicking or disabling MTE when executing KASAN tests (those do multiple bad accesses one after another).

The problem is that for MTE synchronous tag check faults, the access has not happened, so you basically introduce memory corruption by skipping the access.

Quoted 2 lines

We do arm64_skip_faulting_instruction() for software tag-based KASAN too, it's not ideal, but works for testing purposes.

IIUC, KASAN only skips over the brk instruction which doesn't have any other side-effects. Has the actual memory access taken place when it hits the brk?

Quoted 2 lines

Can we disable MTE, reexecute the instruction, and then reenable MTE, or something like that?

If you want to preserve the MTE enabled, you could single-step the instruction or execute it out of line, though it's a bit more convoluted (we have a similar mechanism for kprobes/uprobes).

Another option would be to attempt to set the matching tag in memory, under the assumption that it is writable (if it's not, maybe it's fine to panic). Not sure how this interacts with the slub allocator since, presumably, the logical tag in the pointer is wrong rather than the allocation one.

Yet another option would be to change the tag in the register and re-execute but this may confuse the compiler.

Quoted 3 lines

When running in-kernel MTE in production, we'll either panic or disable MTE after the first fault. This was controlled by the panic_on_mte_fault option Vincenzo initially had.

I prefer to disable MTE, print something and continue, but no panic.

Quoted 3 lines
Quoted 1 line

We only skip if we emulated it.

I'm not sure I understand this part, what do you mean by emulating?

Executing it out of line or other form of instruction emulation (see arch/arm64/kernel/probes/simulate-insn.c) so that the access actually takes place. But you can single-step or experiment with some of the other tricks above.

Signature · 1 line
Catalin
#38 lore raw

Re: [PATCH 21/35] arm64: mte: Add in-kernel tag fault handler

Quoted 17 lines · Catalin Marinas
Quoted 15 lines · Andrey Konovalov
Quoted 12 lines · Catalin Marinas

arch/arm64/mm/fault.c static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs) · line 698

Quoted 7 lines · Andrey Konovalov
arch/arm64/mm/fault.c +7 -0
+static int do_tag_recovery(unsigned long addr, unsigned int esr,
+                        struct pt_regs *regs)
+{
+     report_tag_fault(addr, esr, regs);
+
+     /* Skip over the faulting instruction and continue: */
+     arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE);

Ooooh, do we expect the kernel to still behave correctly after this? I thought the recovery means disabling tag checking altogether and restarting the instruction rather than skipping over it.

Quoted 7 lines
Quoted 3 lines

The intention is to be able to catch multiple MTE faults without panicking or disabling MTE when executing KASAN tests (those do multiple bad accesses one after another).

The problem is that for MTE synchronous tag check faults, the access has not happened, so you basically introduce memory corruption by skipping the access.

Yes, you're right.

Quoted 5 lines
Quoted 2 lines

We do arm64_skip_faulting_instruction() for software tag-based KASAN too, it's not ideal, but works for testing purposes.

IIUC, KASAN only skips over the brk instruction which doesn't have any other side-effects.

Oh, yes, indeed. For some reason I confused myself thinking that we also skip the access for software KASAN.

Quoted 2 lines

Has the actual memory access taken place when it
hits the brk?

IIRC, no, but it will be executed right after we skip the brk.

Quoted 7 lines
Quoted 2 lines

Can we disable MTE, reexecute the instruction, and then reenable MTE, or something like that?

If you want to preserve the MTE enabled, you could single-step the instruction or execute it out of line, though it's a bit more convoluted (we have a similar mechanism for kprobes/uprobes).

Quoted 8 lines

Another option would be to attempt to set the matching tag in memory, under the assumption that it is writable (if it's not, maybe it's fine to panic). Not sure how this interacts with the slub allocator since, presumably, the logical tag in the pointer is wrong rather than the allocation one.

Yet another option would be to change the tag in the register and re-execute but this may confuse the compiler.

Which one of these would be simpler to implement?

Perhaps we could somehow only skip faulting instructions that happen in the KASAN test module?.. Decoding stack trace would be an option, but that's a bit weird.

Overall, this feature is not essential, but will make testing simpler.

Quoted 5 lines
Quoted 3 lines

When running in-kernel MTE in production, we'll either panic or disable MTE after the first fault. This was controlled by the panic_on_mte_fault option Vincenzo initially had.

I prefer to disable MTE, print something and continue, but no panic.

OK, we can do this.

Quoted 11 lines
Quoted 3 lines
Quoted 1 line

We only skip if we emulated it.

I'm not sure I understand this part, what do you mean by emulating?

Executing it out of line or other form of instruction emulation (see arch/arm64/kernel/probes/simulate-insn.c) so that the access actually takes place. But you can single-step or experiment with some of the other tricks above.

--
Catalin

maintainer
#39 lore raw

Re: [PATCH 21/35] arm64: mte: Add in-kernel tag fault handler

Quoted 16 lines · Andrey Konovalov
Quoted 15 lines · Catalin Marinas
Quoted 14 lines · Andrey Konovalov
Quoted 12 lines · Catalin Marinas

arch/arm64/mm/fault.c static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs) · line 698

Quoted 7 lines · Andrey Konovalov
arch/arm64/mm/fault.c +7 -0
+static int do_tag_recovery(unsigned long addr, unsigned int esr,
+                        struct pt_regs *regs)
+{
+     report_tag_fault(addr, esr, regs);
+
+     /* Skip over the faulting instruction and continue: */
+     arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE);

Ooooh, do we expect the kernel to still behave correctly after this? I thought the recovery means disabling tag checking altogether and restarting the instruction rather than skipping over it.

[...]

Quoted 13 lines
Quoted 13 lines
Quoted 2 lines

Can we disable MTE, reexecute the instruction, and then reenable MTE, or something like that?

If you want to preserve the MTE enabled, you could single-step the instruction or execute it out of line, though it's a bit more convoluted (we have a similar mechanism for kprobes/uprobes).

Another option would be to attempt to set the matching tag in memory, under the assumption that it is writable (if it's not, maybe it's fine to panic). Not sure how this interacts with the slub allocator since, presumably, the logical tag in the pointer is wrong rather than the allocation one.

Quoted 4 lines
Quoted 2 lines

Yet another option would be to change the tag in the register and re-execute but this may confuse the compiler.

Which one of these would be simpler to implement?

Either 2 or 3 would be simpler (re-tag the memory location or the pointer) with the caveats I mentioned. Also, does the slab allocator need to touch the memory on free with a tagged pointer? Otherwise slab may hit an MTE fault itself.

Quoted 3 lines

Perhaps we could somehow only skip faulting instructions that happen in the KASAN test module?.. Decoding stack trace would be an option, but that's a bit weird.

If you want to restrict this to the KASAN tests, just add some MTE-specific accessors with a fixup entry similar to get_user/put_user. __do_kernel_fault() (if actually called) will invoke the fixup code which skips the access and returns an error. This way KASAN tests can actually verify that tag checking works, I'd find this a lot more useful.

Signature · 1 line
Catalin
#40 lore raw

Re: [PATCH 21/35] arm64: mte: Add in-kernel tag fault handler

Quoted 35 lines · Catalin Marinas
Quoted 16 lines · Andrey Konovalov
Quoted 15 lines · Catalin Marinas
Quoted 14 lines · Andrey Konovalov
Quoted 12 lines · Catalin Marinas

arch/arm64/mm/fault.c static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs) · line 698

Quoted 7 lines · Andrey Konovalov
arch/arm64/mm/fault.c +7 -0
+static int do_tag_recovery(unsigned long addr, unsigned int esr,
+                        struct pt_regs *regs)
+{
+     report_tag_fault(addr, esr, regs);
+
+     /* Skip over the faulting instruction and continue: */
+     arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE);

Ooooh, do we expect the kernel to still behave correctly after this? I thought the recovery means disabling tag checking altogether and restarting the instruction rather than skipping over it.

[...]

Quoted 16 lines
Quoted 15 lines
Quoted 2 lines

Can we disable MTE, reexecute the instruction, and then reenable MTE, or something like that?

If you want to preserve the MTE enabled, you could single-step the instruction or execute it out of line, though it's a bit more convoluted (we have a similar mechanism for kprobes/uprobes).

Another option would be to attempt to set the matching tag in memory, under the assumption that it is writable (if it's not, maybe it's fine to panic). Not sure how this interacts with the slub allocator since, presumably, the logical tag in the pointer is wrong rather than the allocation one.

Yet another option would be to change the tag in the register and re-execute but this may confuse the compiler.

Quoted 6 lines
Quoted 1 line

Which one of these would be simpler to implement?

Either 2 or 3 would be simpler (re-tag the memory location or the pointer) with the caveats I mentioned. Also, does the slab allocator need to touch the memory on free with a tagged pointer? Otherwise slab may hit an MTE fault itself.

Changing the memory tag can cause faults in other threads, and that could be very confusing.
Probably the safest thing is to retag the register, single step and then retag it back, but be careful with the instructions that change the address register (like ldr x0, [x0]).

Quoted 14 lines
Quoted 4 lines

Perhaps we could somehow only skip faulting instructions that happen in the KASAN test module?.. Decoding stack trace would be an option, but that's a bit weird.

If you want to restrict this to the KASAN tests, just add some MTE-specific accessors with a fixup entry similar to get_user/put_user. __do_kernel_fault() (if actually called) will invoke the fixup code which skips the access and returns an error. This way KASAN tests can actually verify that tag checking works, I'd find this a lot more useful.

--
Catalin

maintainer
#41 lore raw

Re: [PATCH 21/35] arm64: mte: Add in-kernel tag fault handler

Quoted 37 lines · Evgenii Stepanov
Quoted 36 lines · Catalin Marinas
Quoted 16 lines · Andrey Konovalov
Quoted 15 lines · Catalin Marinas
Quoted 14 lines · Andrey Konovalov
Quoted 12 lines · Catalin Marinas

Review

Quoted 7 lines · Andrey Konovalov
(quoted diff) +7 -0
+static int do_tag_recovery(unsigned long addr, unsigned int esr,
+                        struct pt_regs *regs)
+{
+     report_tag_fault(addr, esr, regs);
+
+     /* Skip over the faulting instruction and continue: */
+     arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE);

Ooooh, do we expect the kernel to still behave correctly after this? I thought the recovery means disabling tag checking altogether and restarting the instruction rather than skipping over it.

[...]

Quoted 17 lines
Quoted 7 lines
Quoted 2 lines

Can we disable MTE, reexecute the instruction, and then reenable MTE, or something like that?

If you want to preserve the MTE enabled, you could single-step the instruction or execute it out of line, though it's a bit more convoluted (we have a similar mechanism for kprobes/uprobes).

Quoted 8 lines

Another option would be to attempt to set the matching tag in memory, under the assumption that it is writable (if it's not, maybe it's fine to panic). Not sure how this interacts with the slub allocator since, presumably, the logical tag in the pointer is wrong rather than the allocation one.

Yet another option would be to change the tag in the register and re-execute but this may confuse the compiler.

Which one of these would be simpler to implement?

Quoted 7 lines
Quoted 4 lines

Either 2 or 3 would be simpler (re-tag the memory location or the pointer) with the caveats I mentioned. Also, does the slab allocator need to touch the memory on free with a tagged pointer? Otherwise slab may hit an MTE fault itself.

Changing the memory tag can cause faults in other threads, and that could be very confusing.

It could indeed trigger a chain of faults. It's not even other threads, it could be the same thread in a different function.

Quoted 3 lines

Probably the safest thing is to retag the register, single step and then retag it back, but be careful with the instructions that change the address register (like ldr x0, [x0]).

This gets complicated if you have to parse the opcode. If you can single-step, just set PSTATE.TCO for the instruction. But the single-step machinery gets more complicated, probably interacts badly with kprobes.

I think the best option is to disable the MTE checks in TCF on an _unhandled_ kernel fault, report and continue. For the KASAN tests, add accessors similar to get_user/put_user which are able to handle the fault and return an error. Such accessors, since they have a fixup handler, would not lead to the MTE checks being disabled.

Signature · 1 line
Catalin
#42 lore raw

PATCH 22/35 arm64: mte: Enable in-kernel MTE

In reply to Andrey Konovalov

From: Vincenzo Frascino <[email protected]>

The Tag Checking operation causes a synchronous data abort as a consequence of a tag check fault when MTE is configured in synchronous mode.

Enable MTE in Synchronous mode in EL1 to provide a more immediate way of tag check failure detection in the kernel.

As part of this change enable match-all tag for EL1 to allow the kernel to access user pages without faulting. This is required because the kernel does not have knowledge of the tags set by the user in a page.

Note: For MTE, the TCF bit field in SCTLR_EL1 affects only EL1 in a similar way as TCF0 affects EL0.

---
 arch/arm64/kernel/cpufeature.c | 6 ++++++
 1 file changed, 6 insertions(+)
arch/arm64/kernel/cpufeature.c +6 -0
index 4d3abb51f7d4..4d94af19d8f6 100644
@@ -1670,6 +1670,9 @@ static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap)
 	write_sysreg_s(0, SYS_TFSR_EL1);
 	write_sysreg_s(0, SYS_TFSRE0_EL1);
 
+	/* Enable Match-All at EL1 */
+	sysreg_clear_set(tcr_el1, 0, SYS_TCR_EL1_TCMA1);
+
 	/*
 	 * CnP must be enabled only after the MAIR_EL1 register has been set
 	 * up. Inconsistent MAIR_EL1 between CPUs sharing the same TLB may
@@ -1687,6 +1690,9 @@ static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap)
 	mair &= ~MAIR_ATTRIDX(MAIR_ATTR_MASK, MT_NORMAL_TAGGED);
 	mair |= MAIR_ATTRIDX(MAIR_ATTR_NORMAL_TAGGED, MT_NORMAL_TAGGED);
 	write_sysreg_s(mair, SYS_MAIR_EL1);
+
+	/* Enable MTE Sync Mode for EL1 */
+	sysreg_clear_set(sctlr_el1, SCTLR_ELx_TCF_MASK, SCTLR_ELx_TCF_SYNC);
 	isb();
 
 	local_flush_tlb_all();
Signature · 1 line
2.28.0.220.ged08abb693-goog
maintainer
#43 lore raw

Re: [PATCH 22/35] arm64: mte: Enable in-kernel MTE

Quoted 15 lines · Andrey Konovalov
arch/arm64/kernel/cpufeature.c +3 -0
index 4d3abb51f7d4..4d94af19d8f6 100644
@@ -1670,6 +1670,9 @@ static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap)
 	write_sysreg_s(0, SYS_TFSR_EL1);
 	write_sysreg_s(0, SYS_TFSRE0_EL1);
 
+	/* Enable Match-All at EL1 */
+	sysreg_clear_set(tcr_el1, 0, SYS_TCR_EL1_TCMA1);
+
 	/*
 	 * CnP must be enabled only after the MAIR_EL1 register has been set
 	 * up. Inconsistent MAIR_EL1 between CPUs sharing the same TLB may

arch/arm64/kernel/cpufeature.c static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap) · line 1695

Quoted 6 lines
arch/arm64/kernel/cpufeature.c +3 -0
@@ -1687,6 +1690,9 @@ static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap)
 	mair &= ~MAIR_ATTRIDX(MAIR_ATTR_MASK, MT_NORMAL_TAGGED);
 	mair |= MAIR_ATTRIDX(MAIR_ATTR_NORMAL_TAGGED, MT_NORMAL_TAGGED);
 	write_sysreg_s(mair, SYS_MAIR_EL1);
+
+	/* Enable MTE Sync Mode for EL1 */
+	sysreg_clear_set(sctlr_el1, SCTLR_ELx_TCF_MASK, SCTLR_ELx_TCF_SYNC);

In the 8th incarnation of the user MTE patches, this initialisation moved to proc.S before the MMU is initialised. When rebasing, please take this into account.

Signature · 1 line
Catalin
#44 lore raw

Re: [PATCH 22/35] arm64: mte: Enable in-kernel MTE

Quoted 18 lines · Catalin Marinas
Quoted 17 lines · Andrey Konovalov
arch/arm64/kernel/cpufeature.c +3 -0
index 4d3abb51f7d4..4d94af19d8f6 100644
@@ -1670,6 +1670,9 @@ static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap)
 	write_sysreg_s(0, SYS_TFSR_EL1);
 	write_sysreg_s(0, SYS_TFSRE0_EL1);
 
+	/* Enable Match-All at EL1 */
+	sysreg_clear_set(tcr_el1, 0, SYS_TCR_EL1_TCMA1);
+
 	/*
 	 * CnP must be enabled only after the MAIR_EL1 register has been set
 	 * up. Inconsistent MAIR_EL1 between CPUs sharing the same TLB may
@@ -1687,6 +1690,9 @@ static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap)
 	mair &= ~MAIR_ATTRIDX(MAIR_ATTR_MASK, MT_NORMAL_TAGGED);
 	mair |= MAIR_ATTRIDX(MAIR_ATTR_NORMAL_TAGGED, MT_NORMAL_TAGGED);
Quoted 9 lines

arch/arm64/kernel/cpufeature.c static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap) · line 1695

Quoted 4 lines
arch/arm64/kernel/cpufeature.c +3 -0
 	write_sysreg_s(mair, SYS_MAIR_EL1);
+
+	/* Enable MTE Sync Mode for EL1 */
+	sysreg_clear_set(sctlr_el1, SCTLR_ELx_TCF_MASK, SCTLR_ELx_TCF_SYNC);

In the 8th incarnation of the user MTE patches, this initialisation moved to proc.S before the MMU is initialised. When rebasing, please take this into account.

Thank you for the heads up.

Signature · 2 lines
Regards,
Vincenzo
#45 lore raw

Re: [PATCH 22/35] arm64: mte: Enable in-kernel MTE

In reply to Andrey Konovalov
Quoted 48 lines · Andrey Konovalov

From: Vincenzo Frascino <[email protected]>

The Tag Checking operation causes a synchronous data abort as a consequence of a tag check fault when MTE is configured in synchronous mode.

Enable MTE in Synchronous mode in EL1 to provide a more immediate way of tag check failure detection in the kernel.

As part of this change enable match-all tag for EL1 to allow the kernel to access user pages without faulting. This is required because the kernel does not have knowledge of the tags set by the user in a page.

Note: For MTE, the TCF bit field in SCTLR_EL1 affects only EL1 in a similar way as TCF0 affects EL0.

---
 arch/arm64/kernel/cpufeature.c | 6 ++++++
 1 file changed, 6 insertions(+)
arch/arm64/kernel/cpufeature.c +6 -1
index 4d3abb51f7d4..4d94af19d8f6 100644
@@ -1670,6 +1670,9 @@ static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap)
        write_sysreg_s(0, SYS_TFSR_EL1);
        write_sysreg_s(0, SYS_TFSRE0_EL1);
 
+       /* Enable Match-All at EL1 */
+       sysreg_clear_set(tcr_el1, 0, SYS_TCR_EL1_TCMA1);
+
        /*
         * CnP must be enabled only after the MAIR_EL1 register has been set
         * up. Inconsistent MAIR_EL1 between CPUs sharing the same TLB may
@@ -1687,6 +1690,9 @@ static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap)
        mair &= ~MAIR_ATTRIDX(MAIR_ATTR_MASK, MT_NORMAL_TAGGED);
        mair |= MAIR_ATTRIDX(MAIR_ATTR_NORMAL_TAGGED, MT_NORMAL_TAGGED);
        write_sysreg_s(mair, SYS_MAIR_EL1);
+
+       /* Enable MTE Sync Mode for EL1 */
+       sysreg_clear_set(sctlr_el1, SCTLR_ELx_TCF_MASK, SCTLR_ELx_TCF_SYNC);
        isb();
 
        local_flush_tlb_all();
--
Quoted 2 lines

2.28.0.220.ged08abb693-goog

Should we change this commit to enable in-kernel MTE only if KASAN_HW_TAGS is enabled?

maintainer
#46 lore raw

Re: [PATCH 22/35] arm64: mte: Enable in-kernel MTE

Quoted 46 lines · Andrey Konovalov
Quoted 45 lines · Andrey Konovalov

From: Vincenzo Frascino <[email protected]>

The Tag Checking operation causes a synchronous data abort as a consequence of a tag check fault when MTE is configured in synchronous mode.

Enable MTE in Synchronous mode in EL1 to provide a more immediate way of tag check failure detection in the kernel.

As part of this change enable match-all tag for EL1 to allow the kernel to access user pages without faulting. This is required because the kernel does not have knowledge of the tags set by the user in a page.

Note: For MTE, the TCF bit field in SCTLR_EL1 affects only EL1 in a similar way as TCF0 affects EL0.

---
 arch/arm64/kernel/cpufeature.c | 6 ++++++
 1 file changed, 6 insertions(+)
arch/arm64/kernel/cpufeature.c +6 -0
index 4d3abb51f7d4..4d94af19d8f6 100644
@@ -1670,6 +1670,9 @@ static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap)
        write_sysreg_s(0, SYS_TFSR_EL1);
        write_sysreg_s(0, SYS_TFSRE0_EL1);
 
+       /* Enable Match-All at EL1 */
+       sysreg_clear_set(tcr_el1, 0, SYS_TCR_EL1_TCMA1);
+
        /*
         * CnP must be enabled only after the MAIR_EL1 register has been set
         * up. Inconsistent MAIR_EL1 between CPUs sharing the same TLB may
@@ -1687,6 +1690,9 @@ static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap)
        mair &= ~MAIR_ATTRIDX(MAIR_ATTR_MASK, MT_NORMAL_TAGGED);
        mair |= MAIR_ATTRIDX(MAIR_ATTR_NORMAL_TAGGED, MT_NORMAL_TAGGED);
        write_sysreg_s(mair, SYS_MAIR_EL1);
+
+       /* Enable MTE Sync Mode for EL1 */
+       sysreg_clear_set(sctlr_el1, SCTLR_ELx_TCF_MASK, SCTLR_ELx_TCF_SYNC);
        isb();
 
Quoted 7 lines
Quoted 4 lines
arch/arm64/kernel/cpufeature.c +0 -1
        local_flush_tlb_all();
--

2.28.0.220.ged08abb693-goog

Should we change this commit to enable in-kernel MTE only if KASAN_HW_TAGS is enabled?

I think so. We don't currently have any patchset decoupling MTE from KASAN.

See my other comment on TCR_EL1.TBI1, you'd need to set TCMA1 as well in the same proc.S file.

Signature · 1 line
Catalin
#47 lore raw

PATCH 23/35 arm64: mte: Convert gcr_user into an exclude mask

In reply to Andrey Konovalov

From: Vincenzo Frascino <[email protected]>

The gcr_user mask is a per thread mask that represents the tags that are excluded from random generation when the Memory Tagging Extension is present and an 'irg' instruction is invoked.

gcr_user affects the behavior on EL0 only.

Currently that mask is an include mask and it is controlled by the user via prctl() while GCR_EL1 accepts an exclude mask.

Convert the include mask into an exclude one to make it easier the register setting.

Note: This change will affect gcr_kernel (for EL1) introduced with a future patch.

---
 arch/arm64/include/asm/processor.h |  2 +-
 arch/arm64/kernel/mte.c            | 29 +++++++++++++++--------------
 2 files changed, 16 insertions(+), 15 deletions(-)
arch/arm64/include/asm/processor.h +1 -1
index fec204d28fce..ed9efa5be8eb 100644
@@ -153,7 +153,7 @@ struct thread_struct {
 #endif
 #ifdef CONFIG_ARM64_MTE
 	u64			sctlr_tcf0;
-	u64			gcr_user_incl;
+	u64			gcr_user_excl;
 #endif
 };
 
arch/arm64/kernel/mte.c +15 -14
index e2d708b4583d..7717ea9bc2a7 100644
@@ -135,23 +135,22 @@ static void set_sctlr_el1_tcf0(u64 tcf0)
 	preempt_enable();
 }
 
-static void update_gcr_el1_excl(u64 incl)
+static void update_gcr_el1_excl(u64 excl)
 {
-	u64 excl = ~incl & SYS_GCR_EL1_EXCL_MASK;
 
 	/*
-	 * Note that 'incl' is an include mask (controlled by the user via
-	 * prctl()) while GCR_EL1 accepts an exclude mask.
+	 * Note that the mask controlled by the user via prctl() is an
+	 * include while GCR_EL1 accepts an exclude mask.
 	 * No need for ISB since this only affects EL0 currently, implicit
 	 * with ERET.
 	 */
 	sysreg_clear_set_s(SYS_GCR_EL1, SYS_GCR_EL1_EXCL_MASK, excl);
 }
 
-static void set_gcr_el1_excl(u64 incl)
+static void set_gcr_el1_excl(u64 excl)
 {
-	current->thread.gcr_user_incl = incl;
-	update_gcr_el1_excl(incl);
+	current->thread.gcr_user_excl = excl;
+	update_gcr_el1_excl(excl);
 }
 
 void flush_mte_state(void)
@@ -166,7 +165,7 @@ void flush_mte_state(void)
 	/* disable tag checking */
 	set_sctlr_el1_tcf0(SCTLR_EL1_TCF0_NONE);
 	/* reset tag generation mask */
-	set_gcr_el1_excl(0);
+	set_gcr_el1_excl(SYS_GCR_EL1_EXCL_MASK);
 }
 
 void mte_thread_switch(struct task_struct *next)
@@ -177,7 +176,7 @@ void mte_thread_switch(struct task_struct *next)
 	/* avoid expensive SCTLR_EL1 accesses if no change */
 	if (current->thread.sctlr_tcf0 != next->thread.sctlr_tcf0)
 		update_sctlr_el1_tcf0(next->thread.sctlr_tcf0);
-	update_gcr_el1_excl(next->thread.gcr_user_incl);
+	update_gcr_el1_excl(next->thread.gcr_user_excl);
 }
 
 void mte_suspend_exit(void)
@@ -185,13 +184,14 @@ void mte_suspend_exit(void)
 	if (!system_supports_mte())
 		return;
 
-	update_gcr_el1_excl(current->thread.gcr_user_incl);
+	update_gcr_el1_excl(current->thread.gcr_user_excl);
 }
 
 long set_mte_ctrl(struct task_struct *task, unsigned long arg)
 {
 	u64 tcf0;
-	u64 gcr_incl = (arg & PR_MTE_TAG_MASK) >> PR_MTE_TAG_SHIFT;
+	u64 gcr_excl = ~((arg & PR_MTE_TAG_MASK) >> PR_MTE_TAG_SHIFT) &
+		       SYS_GCR_EL1_EXCL_MASK;
 
 	if (!system_supports_mte())
 		return 0;
@@ -212,10 +212,10 @@ long set_mte_ctrl(struct task_struct *task, unsigned long arg)
 
 	if (task != current) {
 		task->thread.sctlr_tcf0 = tcf0;
-		task->thread.gcr_user_incl = gcr_incl;
+		task->thread.gcr_user_excl = gcr_excl;
 	} else {
 		set_sctlr_el1_tcf0(tcf0);
-		set_gcr_el1_excl(gcr_incl);
+		set_gcr_el1_excl(gcr_excl);
 	}
 
 	return 0;
@@ -224,11 +224,12 @@ long set_mte_ctrl(struct task_struct *task, unsigned long arg)
 long get_mte_ctrl(struct task_struct *task)
 {
 	unsigned long ret;
+	u64 incl = ~task->thread.gcr_user_excl & SYS_GCR_EL1_EXCL_MASK;
 
 	if (!system_supports_mte())
 		return 0;
 
-	ret = task->thread.gcr_user_incl << PR_MTE_TAG_SHIFT;
+	ret = incl << PR_MTE_TAG_SHIFT;
 
 	switch (task->thread.sctlr_tcf0) {
 	case SCTLR_EL1_TCF0_NONE:
Signature · 1 line
2.28.0.220.ged08abb693-goog
#48 lore raw

PATCH 24/35 arm64: mte: Switch GCR_EL1 in kernel entry and exit

In reply to Andrey Konovalov

From: Vincenzo Frascino <[email protected]>

When MTE is present, the GCR_EL1 register contains the tags mask that allows to exclude tags from the random generation via the IRG instruction.

With the introduction of the new Tag-Based KASAN API that provides a mechanism to reserve tags for special reasons, the MTE implementation has to make sure that the GCR_EL1 setting for the kernel does not affect the userspace processes and viceversa.

Save and restore the kernel/user mask in GCR_EL1 in kernel entry and exit.

---
 arch/arm64/include/asm/mte.h    |  8 ++++++++
 arch/arm64/kernel/asm-offsets.c |  3 +++
 arch/arm64/kernel/cpufeature.c  |  5 +++--
 arch/arm64/kernel/entry.S       | 28 ++++++++++++++++++++++++++++
 arch/arm64/kernel/mte.c         | 19 +++++++++++++++++--
 5 files changed, 59 insertions(+), 4 deletions(-)
arch/arm64/include/asm/mte.h +8 -0
index 733be1cb5c95..4929f744d103 100644
@@ -21,6 +21,8 @@
 
 #include <asm/pgtable-types.h>
 
+extern u64 gcr_kernel_excl;
+
 void mte_clear_page_tags(void *addr);
 unsigned long mte_copy_tags_from_user(void *to, const void __user *from,
 				      unsigned long n);
@@ -59,6 +61,8 @@ u8 mte_get_mem_tag(void *addr);
 u8 mte_get_random_tag(void);
 void *mte_set_mem_tag_range(void *addr, size_t size, u8 tag);
 
+void mte_init_tags(u64 max_tag);
+
 #else /* CONFIG_ARM64_MTE */
 
 /* unused if !CONFIG_ARM64_MTE, silence the compiler */
@@ -120,6 +124,10 @@ static inline void *mte_set_mem_tag_range(void *addr, size_t size, u8 tag)
 	return addr;
 }
 
+static inline void mte_init_tags(u64 max_tag)
+{
+}
+
 #endif /* CONFIG_ARM64_MTE */
 
 #endif /* __ASSEMBLY__ */
arch/arm64/kernel/asm-offsets.c +3 -0
index 0577e2142284..a1ef256cad4f 100644
@@ -47,6 +47,9 @@ int main(void)
 #ifdef CONFIG_ARM64_PTR_AUTH
   DEFINE(THREAD_KEYS_USER,	offsetof(struct task_struct, thread.keys_user));
   DEFINE(THREAD_KEYS_KERNEL,	offsetof(struct task_struct, thread.keys_kernel));
+#endif
+#ifdef CONFIG_ARM64_MTE
+  DEFINE(THREAD_GCR_EL1_USER,	offsetof(struct task_struct, thread.gcr_user_excl));
 #endif
   BLANK();
   DEFINE(S_X0,			offsetof(struct pt_regs, regs[0]));
arch/arm64/kernel/cpufeature.c +3 -2
index 4d94af19d8f6..54bc3b315063 100644
@@ -1665,14 +1665,15 @@ static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap)
 {
 	u64 mair;
 
-	/* all non-zero tags excluded by default */
-	write_sysreg_s(SYS_GCR_EL1_RRND | SYS_GCR_EL1_EXCL_MASK, SYS_GCR_EL1);
 	write_sysreg_s(0, SYS_TFSR_EL1);
 	write_sysreg_s(0, SYS_TFSRE0_EL1);
 
 	/* Enable Match-All at EL1 */
 	sysreg_clear_set(tcr_el1, 0, SYS_TCR_EL1_TCMA1);
 
+	/* Enable the kernel exclude mask for random tags generation */
+	write_sysreg_s((SYS_GCR_EL1_RRND | gcr_kernel_excl), SYS_GCR_EL1);
+
 	/*
 	 * CnP must be enabled only after the MAIR_EL1 register has been set
 	 * up. Inconsistent MAIR_EL1 between CPUs sharing the same TLB may
arch/arm64/kernel/entry.S +28 -0
index cde127508e38..a17fefb0571b 100644
@@ -172,6 +172,29 @@ alternative_else_nop_endif
 #endif
 	.endm
 
+	/* Note: tmp should always be a callee-saved register */
+	.macro mte_restore_gcr, el, tsk, tmp, tmp2
+#ifdef CONFIG_ARM64_MTE
+alternative_if_not ARM64_MTE
+	b	1f
+alternative_else_nop_endif
+	.if	\el == 0
+	ldr	\tmp, [\tsk, #THREAD_GCR_EL1_USER]
+	.else
+	ldr_l	\tmp, gcr_kernel_excl
+	.endif
+	/*
+	 * Calculate and set the exclude mask preserving
+	 * the RRND (bit[16]) setting.
+	 */
+	mrs_s	\tmp2, SYS_GCR_EL1
+	bfi	\tmp2, \tmp, #0, #16
+	msr_s	SYS_GCR_EL1, \tmp2
+	isb
+1:
+#endif
+	.endm
+
 	.macro	kernel_entry, el, regsize = 64
 	.if	\regsize == 32
 	mov	w0, w0				// zero upper 32 bits of x0
@@ -209,6 +232,8 @@ alternative_else_nop_endif
 
 	ptrauth_keys_install_kernel tsk, x20, x22, x23
 
+	mte_restore_gcr 1, tsk, x22, x23
+
 	scs_load tsk, x20
 	.else
 	add	x21, sp, #S_FRAME_SIZE
@@ -386,6 +411,8 @@ alternative_else_nop_endif
 	/* No kernel C function calls after this as user keys are set. */
 	ptrauth_keys_install_user tsk, x0, x1, x2
 
+	mte_restore_gcr 0, tsk, x0, x1
+
 	apply_ssbd 0, x0, x1
 	.endif
 
@@ -957,6 +984,7 @@ SYM_FUNC_START(cpu_switch_to)
 	mov	sp, x9
 	msr	sp_el0, x1
 	ptrauth_keys_install_kernel x1, x8, x9, x10
+	mte_restore_gcr 1, x1, x8, x9
 	scs_save x0, x8
 	scs_load x1, x8
 	ret
arch/arm64/kernel/mte.c +17 -2
index 7717ea9bc2a7..cfac7d02f032 100644
@@ -18,10 +18,14 @@
 
 #include <asm/barrier.h>
 #include <asm/cpufeature.h>
+#include <asm/kasan.h>
+#include <asm/kprobes.h>
 #include <asm/mte.h>
 #include <asm/ptrace.h>
 #include <asm/sysreg.h>
 
+u64 gcr_kernel_excl __read_mostly;
+
 static void mte_sync_page_tags(struct page *page, pte_t *ptep, bool check_swap)
 {
 	pte_t old_pte = READ_ONCE(*ptep);
@@ -115,6 +119,13 @@ void * __must_check mte_set_mem_tag_range(void *addr, size_t size, u8 tag)
 	return ptr;
 }
 
+void mte_init_tags(u64 max_tag)
+{
+	u64 incl = ((1ULL << ((max_tag & MTE_TAG_MAX) + 1)) - 1);
+
+	gcr_kernel_excl = ~incl & SYS_GCR_EL1_EXCL_MASK;
+}
+
 static void update_sctlr_el1_tcf0(u64 tcf0)
 {
 	/* ISB required for the kernel uaccess routines */
@@ -150,7 +161,11 @@ static void update_gcr_el1_excl(u64 excl)
 static void set_gcr_el1_excl(u64 excl)
 {
 	current->thread.gcr_user_excl = excl;
-	update_gcr_el1_excl(excl);
+
+	/*
+	 * SYS_GCR_EL1 will be set to current->thread.gcr_user_incl value
+	 * by mte_restore_gcr() in kernel_exit,
+	 */
 }
 
 void flush_mte_state(void)
@@ -184,7 +199,7 @@ void mte_suspend_exit(void)
 	if (!system_supports_mte())
 		return;
 
-	update_gcr_el1_excl(current->thread.gcr_user_excl);
+	update_gcr_el1_excl(gcr_kernel_excl);
 }
 
 long set_mte_ctrl(struct task_struct *task, unsigned long arg)
Signature · 1 line
2.28.0.220.ged08abb693-goog
maintainer
#49 lore raw

Re: [PATCH 24/35] arm64: mte: Switch GCR_EL1 in kernel entry and exit

arch/arm64/kernel/entry.S alternative_else_nop_endif · line 175

Quoted 9 lines · Andrey Konovalov
arch/arm64/kernel/entry.S +1 -0
index cde127508e38..a17fefb0571b 100644
@@ -172,6 +172,29 @@ alternative_else_nop_endif
 #endif
 	.endm
 
+	/* Note: tmp should always be a callee-saved register */

Why callee-saved? Do you preserve it anywhere here?

Quoted 44 lines
arch/arm64/kernel/entry.S +26 -0
+	.macro mte_restore_gcr, el, tsk, tmp, tmp2
+#ifdef CONFIG_ARM64_MTE
+alternative_if_not ARM64_MTE
+	b	1f
+alternative_else_nop_endif
+	.if	\el == 0
+	ldr	\tmp, [\tsk, #THREAD_GCR_EL1_USER]
+	.else
+	ldr_l	\tmp, gcr_kernel_excl
+	.endif
+	/*
+	 * Calculate and set the exclude mask preserving
+	 * the RRND (bit[16]) setting.
+	 */
+	mrs_s	\tmp2, SYS_GCR_EL1
+	bfi	\tmp2, \tmp, #0, #16
+	msr_s	SYS_GCR_EL1, \tmp2
+	isb
+1:
+#endif
+	.endm
+
 	.macro	kernel_entry, el, regsize = 64
 	.if	\regsize == 32
 	mov	w0, w0				// zero upper 32 bits of x0
@@ -209,6 +232,8 @@ alternative_else_nop_endif
 
 	ptrauth_keys_install_kernel tsk, x20, x22, x23
 
+	mte_restore_gcr 1, tsk, x22, x23
+
 	scs_load tsk, x20
 	.else
 	add	x21, sp, #S_FRAME_SIZE
@@ -386,6 +411,8 @@ alternative_else_nop_endif
 	/* No kernel C function calls after this as user keys are set. */
 	ptrauth_keys_install_user tsk, x0, x1, x2
 
+	mte_restore_gcr 0, tsk, x0, x1
+
 	apply_ssbd 0, x0, x1
 	.endif
 

arch/arm64/kernel/entry.S SYM_FUNC_START(cpu_switch_to) · line 990

Quoted 7 lines
arch/arm64/kernel/entry.S +1 -0
@@ -957,6 +984,7 @@ SYM_FUNC_START(cpu_switch_to)
 	mov	sp, x9
 	msr	sp_el0, x1
 	ptrauth_keys_install_kernel x1, x8, x9, x10
+	mte_restore_gcr 1, x1, x8, x9
 	scs_save x0, x8
 	scs_load x1, x8
 	ret

Since we set GCR_EL1 on exception entry and return, why is this needed? We don't have a per-kernel thread GCR_EL1, it's global to all threads, so I think cpu_switch_to() should not be touched.

Quoted 5 lines
arch/arm64/kernel/mte.c +0 -0
index 7717ea9bc2a7..cfac7d02f032 100644

arch/arm64/kernel/mte.c line 27

Quoted 10 lines
arch/arm64/kernel/mte.c +3 -0
@@ -18,10 +18,14 @@
 
 #include <asm/barrier.h>
 #include <asm/cpufeature.h>
+#include <asm/kasan.h>
+#include <asm/kprobes.h>
 #include <asm/mte.h>
 #include <asm/ptrace.h>
 #include <asm/sysreg.h>
 
+u64 gcr_kernel_excl __read_mostly;

Could we make this __ro_after_init?

arch/arm64/kernel/mte.c void * __must_check mte_set_mem_tag_range(void *addr, size_t size, u8 tag) · line 124

Quoted 11 lines
arch/arm64/kernel/mte.c +4 -0
+
 static void mte_sync_page_tags(struct page *page, pte_t *ptep, bool check_swap)
 {
 	pte_t old_pte = READ_ONCE(*ptep);
@@ -115,6 +119,13 @@ void * __must_check mte_set_mem_tag_range(void *addr, size_t size, u8 tag)
 	return ptr;
 }
 
+void mte_init_tags(u64 max_tag)
+{
+	u64 incl = ((1ULL << ((max_tag & MTE_TAG_MAX) + 1)) - 1);

I'd rather use GENMASK here, it is more readable.

Signature · 1 line
Catalin
#50 lore raw

Re: [PATCH 24/35] arm64: mte: Switch GCR_EL1 in kernel entry and exit

Quoted 9 lines · Catalin Marinas
Quoted 8 lines · Andrey Konovalov
arch/arm64/kernel/entry.S +0 -0
index cde127508e38..a17fefb0571b 100644
@@ -172,6 +172,29 @@ alternative_else_nop_endif
 #endif
 	.endm
 
Quoted 4 lines

arch/arm64/kernel/entry.S alternative_else_nop_endif · line 175

Quoted 1 line
arch/arm64/kernel/entry.S +1 -0
+	/* Note: tmp should always be a callee-saved register */

Why callee-saved? Do you preserve it anywhere here?

Aargh, this is an old comment, I forgot to remove it after the last refactor. Thank you for pointing this out.

Quoted 43 lines
Quoted 43 lines
arch/arm64/kernel/entry.S +26 -0
+	.macro mte_restore_gcr, el, tsk, tmp, tmp2
+#ifdef CONFIG_ARM64_MTE
+alternative_if_not ARM64_MTE
+	b	1f
+alternative_else_nop_endif
+	.if	\el == 0
+	ldr	\tmp, [\tsk, #THREAD_GCR_EL1_USER]
+	.else
+	ldr_l	\tmp, gcr_kernel_excl
+	.endif
+	/*
+	 * Calculate and set the exclude mask preserving
+	 * the RRND (bit[16]) setting.
+	 */
+	mrs_s	\tmp2, SYS_GCR_EL1
+	bfi	\tmp2, \tmp, #0, #16
+	msr_s	SYS_GCR_EL1, \tmp2
+	isb
+1:
+#endif
+	.endm
+
 	.macro	kernel_entry, el, regsize = 64
 	.if	\regsize == 32
 	mov	w0, w0				// zero upper 32 bits of x0
@@ -209,6 +232,8 @@ alternative_else_nop_endif
 
 	ptrauth_keys_install_kernel tsk, x20, x22, x23
 
+	mte_restore_gcr 1, tsk, x22, x23
+
 	scs_load tsk, x20
 	.else
 	add	x21, sp, #S_FRAME_SIZE
@@ -386,6 +411,8 @@ alternative_else_nop_endif
 	/* No kernel C function calls after this as user keys are set. */
 	ptrauth_keys_install_user tsk, x0, x1, x2
 
+	mte_restore_gcr 0, tsk, x0, x1
+
 	apply_ssbd 0, x0, x1
 	.endif
 
Quoted 13 lines

arch/arm64/kernel/entry.S SYM_FUNC_START(cpu_switch_to) · line 990

Quoted 8 lines
arch/arm64/kernel/entry.S +1 -0
@@ -957,6 +984,7 @@ SYM_FUNC_START(cpu_switch_to)
 	mov	sp, x9
 	msr	sp_el0, x1
 	ptrauth_keys_install_kernel x1, x8, x9, x10
+	mte_restore_gcr 1, x1, x8, x9
 	scs_save x0, x8
 	scs_load x1, x8
 	ret

Since we set GCR_EL1 on exception entry and return, why is this needed? We don't have a per-kernel thread GCR_EL1, it's global to all threads, so I think cpu_switch_to() should not be touched.

I agree, we can remove it. We only require the kernel entry and the kernel exit ones.

Quoted 14 lines
Quoted 14 lines
arch/arm64/kernel/mte.c +2 -0
index 7717ea9bc2a7..cfac7d02f032 100644
@@ -18,10 +18,14 @@
 
 #include <asm/barrier.h>
 #include <asm/cpufeature.h>
+#include <asm/kasan.h>
+#include <asm/kprobes.h>
 #include <asm/mte.h>
 #include <asm/ptrace.h>
 #include <asm/sysreg.h>
 
Quoted 4 lines

arch/arm64/kernel/mte.c line 27

Quoted 1 line
arch/arm64/kernel/mte.c +1 -0
+u64 gcr_kernel_excl __read_mostly;

Could we make this __ro_after_init?

Yes, it makes sense, it should be updated only once through mte_init_tags().

Something to consider though here is that this might not be the right approach if in future we want to add stack tagging. In such a case we need to know the kernel exclude mask before any C code is executed. Initializing the mask via mte_init_tags() it is too late.

I was thinking to add a compilation define instead of having gcr_kernel_excl in place. This might not work if the kernel excl mask is meant to change during the execution.

Thoughts?

Quoted 8 lines
Quoted 8 lines
arch/arm64/kernel/mte.c +1 -0
+
 static void mte_sync_page_tags(struct page *page, pte_t *ptep, bool check_swap)
 {
 	pte_t old_pte = READ_ONCE(*ptep);
@@ -115,6 +119,13 @@ void * __must_check mte_set_mem_tag_range(void *addr, size_t size, u8 tag)
 	return ptr;
 }
 
Quoted 6 lines

arch/arm64/kernel/mte.c void * __must_check mte_set_mem_tag_range(void *addr, size_t size, u8 tag) · line 124

Quoted 3 lines
arch/arm64/kernel/mte.c +3 -0
+void mte_init_tags(u64 max_tag)
+{
+	u64 incl = ((1ULL << ((max_tag & MTE_TAG_MAX) + 1)) - 1);

I'd rather use GENMASK here, it is more readable.

Agree, we can change it.

Signature · 2 lines
Regards,
Vincenzo
maintainer
#51 lore raw

Re: [PATCH 24/35] arm64: mte: Switch GCR_EL1 in kernel entry and exit

Quoted 20 lines · Vincenzo Frascino
Quoted 15 lines · Catalin Marinas
Quoted 14 lines · Andrey Konovalov
arch/arm64/kernel/mte.c +2 -0
index 7717ea9bc2a7..cfac7d02f032 100644
@@ -18,10 +18,14 @@
 
 #include <asm/barrier.h>
 #include <asm/cpufeature.h>
+#include <asm/kasan.h>
+#include <asm/kprobes.h>
 #include <asm/mte.h>
 #include <asm/ptrace.h>
 #include <asm/sysreg.h>
 
Quoted 3 lines

arch/arm64/kernel/mte.c line 27

Quoted 1 line
arch/arm64/kernel/mte.c +1 -0
+u64 gcr_kernel_excl __read_mostly;

Could we make this __ro_after_init?

Quoted 6 lines

Yes, it makes sense, it should be updated only once through mte_init_tags().

Something to consider though here is that this might not be the right approach if in future we want to add stack tagging. In such a case we need to know the kernel exclude mask before any C code is executed. Initializing the mask via mte_init_tags() it is too late.

It depends on how stack tagging ends up in the kernel, whether it uses ADDG/SUBG or not. If it's only IRG, I think it can cope with changing the GCR_EL1.Excl in the middle of a function.

Quoted 3 lines

I was thinking to add a compilation define instead of having gcr_kernel_excl in place. This might not work if the kernel excl mask is meant to change during the execution.

A macro with the default value works for me. That's what it basically is currently, only that it ends up in a variable.

Signature · 1 line
Catalin
#52 lore raw

Re: [PATCH 24/35] arm64: mte: Switch GCR_EL1 in kernel entry and exit

Quoted 33 lines · Catalin Marinas
Quoted 20 lines · Vincenzo Frascino
Quoted 15 lines · Catalin Marinas
Quoted 14 lines · Andrey Konovalov
arch/arm64/kernel/mte.c +2 -0
index 7717ea9bc2a7..cfac7d02f032 100644
@@ -18,10 +18,14 @@
 
 #include <asm/barrier.h>
 #include <asm/cpufeature.h>
+#include <asm/kasan.h>
+#include <asm/kprobes.h>
 #include <asm/mte.h>
 #include <asm/ptrace.h>
 #include <asm/sysreg.h>
 
Quoted 3 lines

arch/arm64/kernel/mte.c line 27

Quoted 1 line
arch/arm64/kernel/mte.c +1 -0
+u64 gcr_kernel_excl __read_mostly;

Could we make this __ro_after_init?

Quoted 6 lines

Yes, it makes sense, it should be updated only once through mte_init_tags().

Something to consider though here is that this might not be the right approach if in future we want to add stack tagging. In such a case we need to know the kernel exclude mask before any C code is executed. Initializing the mask via mte_init_tags() it is too late.

It depends on how stack tagging ends up in the kernel, whether it uses ADDG/SUBG or not. If it's only IRG, I think it can cope with changing the GCR_EL1.Excl in the middle of a function.

Quoted 6 lines
Quoted 3 lines

I was thinking to add a compilation define instead of having gcr_kernel_excl in place. This might not work if the kernel excl mask is meant to change during the execution.

A macro with the default value works for me. That's what it basically is currently, only that it ends up in a variable.

Some thoughts on the topic: gcr_kernel_excl is currently initialized in mte_init_tags() and depends on the max_tag value dynamically provided to it, so it's not something that can be expressed with a define. In the case of KASAN the max_tag value is static, but if we rely on that we make core MTE code depend on KASAN, which doesn't seem right from the design perspective.

#53 lore raw

Re: [PATCH 24/35] arm64: mte: Switch GCR_EL1 in kernel entry and exit

Quoted 42 lines · Andrey Konovalov
Quoted 33 lines · Catalin Marinas
Quoted 20 lines · Vincenzo Frascino
Quoted 15 lines · Catalin Marinas
Quoted 14 lines · Andrey Konovalov
arch/arm64/kernel/mte.c +2 -0
index 7717ea9bc2a7..cfac7d02f032 100644
@@ -18,10 +18,14 @@
 
 #include <asm/barrier.h>
 #include <asm/cpufeature.h>
+#include <asm/kasan.h>
+#include <asm/kprobes.h>
 #include <asm/mte.h>
 #include <asm/ptrace.h>
 #include <asm/sysreg.h>
 
Quoted 3 lines

arch/arm64/kernel/mte.c line 27

Quoted 1 line
arch/arm64/kernel/mte.c +1 -0
+u64 gcr_kernel_excl __read_mostly;

Could we make this __ro_after_init?

Quoted 6 lines

Yes, it makes sense, it should be updated only once through mte_init_tags().

Something to consider though here is that this might not be the right approach if in future we want to add stack tagging. In such a case we need to know the kernel exclude mask before any C code is executed. Initializing the mask via mte_init_tags() it is too late.

It depends on how stack tagging ends up in the kernel, whether it uses ADDG/SUBG or not. If it's only IRG, I think it can cope with changing the GCR_EL1.Excl in the middle of a function.

Quoted 6 lines
Quoted 3 lines

I was thinking to add a compilation define instead of having gcr_kernel_excl in place. This might not work if the kernel excl mask is meant to change during the execution.

A macro with the default value works for me. That's what it basically is currently, only that it ends up in a variable.

Quoted 6 lines

Some thoughts on the topic: gcr_kernel_excl is currently initialized in mte_init_tags() and depends on the max_tag value dynamically provided to it, so it's not something that can be expressed with a define. In the case of KASAN the max_tag value is static, but if we rely on that we make core MTE code depend on KASAN, which doesn't seem right from the design perspective.

Thinking more about this, I think we've actually discussed moving KASAN_MAX_TAG to somewhere in low-level headers, so I guess we can reuse that and make gcr_kernel_excl a define. I'll look into this.

maintainer
#54 lore raw

Re: [PATCH 24/35] arm64: mte: Switch GCR_EL1 in kernel entry and exit

In reply to Andrey Konovalov
Quoted 40 lines · Andrey Konovalov
Quoted 32 lines · Catalin Marinas
Quoted 20 lines · Vincenzo Frascino
Quoted 15 lines · Catalin Marinas
Quoted 14 lines · Andrey Konovalov
arch/arm64/kernel/mte.c +2 -0
index 7717ea9bc2a7..cfac7d02f032 100644
@@ -18,10 +18,14 @@
 
 #include <asm/barrier.h>
 #include <asm/cpufeature.h>
+#include <asm/kasan.h>
+#include <asm/kprobes.h>
 #include <asm/mte.h>
 #include <asm/ptrace.h>
 #include <asm/sysreg.h>
 
Quoted 3 lines

arch/arm64/kernel/mte.c line 27

Quoted 1 line
arch/arm64/kernel/mte.c +1 -0
+u64 gcr_kernel_excl __read_mostly;

Could we make this __ro_after_init?

Quoted 6 lines

Yes, it makes sense, it should be updated only once through mte_init_tags().

Something to consider though here is that this might not be the right approach if in future we want to add stack tagging. In such a case we need to know the kernel exclude mask before any C code is executed. Initializing the mask via mte_init_tags() it is too late.

It depends on how stack tagging ends up in the kernel, whether it uses ADDG/SUBG or not. If it's only IRG, I think it can cope with changing the GCR_EL1.Excl in the middle of a function.

Quoted 6 lines
Quoted 3 lines

I was thinking to add a compilation define instead of having gcr_kernel_excl in place. This might not work if the kernel excl mask is meant to change during the execution.

A macro with the default value works for me. That's what it basically is currently, only that it ends up in a variable.

Quoted 6 lines

Some thoughts on the topic: gcr_kernel_excl is currently initialized in mte_init_tags() and depends on the max_tag value dynamically provided to it, so it's not something that can be expressed with a define. In the case of KASAN the max_tag value is static, but if we rely on that we make core MTE code depend on KASAN, which doesn't seem right from the design perspective.

The design is debatable. If we want MTE to run on production devices, we either (1) optimise out some bits of KASAN (configurable) or (2) we decouple MTE and KASAN completely and add new callbacks in the core code (slab allocator etc.) specific to MTE.

My first choice is (1), unless there is a strong technical argument why it is not possible.

Signature · 1 line
Catalin
#55 lore raw

Re: [PATCH 24/35] arm64: mte: Switch GCR_EL1 in kernel entry and exit

Hello,

Is the branch where the MTE patches currently are being applied for-net/mte? It looks like that's the place, but I want to confirm.

Quoted 64 lines · Catalin Marinas
Quoted 40 lines · Andrey Konovalov
Quoted 32 lines · Catalin Marinas
Quoted 20 lines · Vincenzo Frascino
Quoted 15 lines · Catalin Marinas
Quoted 14 lines · Andrey Konovalov
arch/arm64/kernel/mte.c +2 -0
index 7717ea9bc2a7..cfac7d02f032 100644
@@ -18,10 +18,14 @@
 
 #include <asm/barrier.h>
 #include <asm/cpufeature.h>
+#include <asm/kasan.h>
+#include <asm/kprobes.h>
 #include <asm/mte.h>
 #include <asm/ptrace.h>
 #include <asm/sysreg.h>
 
Quoted 3 lines

arch/arm64/kernel/mte.c line 27

Quoted 1 line
arch/arm64/kernel/mte.c +1 -0
+u64 gcr_kernel_excl __read_mostly;

Could we make this __ro_after_init?

Quoted 6 lines

Yes, it makes sense, it should be updated only once through mte_init_tags().

Something to consider though here is that this might not be the right approach if in future we want to add stack tagging. In such a case we need to know the kernel exclude mask before any C code is executed. Initializing the mask via mte_init_tags() it is too late.

It depends on how stack tagging ends up in the kernel, whether it uses ADDG/SUBG or not. If it's only IRG, I think it can cope with changing the GCR_EL1.Excl in the middle of a function.

Quoted 6 lines
Quoted 3 lines

I was thinking to add a compilation define instead of having gcr_kernel_excl in place. This might not work if the kernel excl mask is meant to change during the execution.

A macro with the default value works for me. That's what it basically is currently, only that it ends up in a variable.

Quoted 6 lines

Some thoughts on the topic: gcr_kernel_excl is currently initialized in mte_init_tags() and depends on the max_tag value dynamically provided to it, so it's not something that can be expressed with a define. In the case of KASAN the max_tag value is static, but if we rely on that we make core MTE code depend on KASAN, which doesn't seem right from the design perspective.

The design is debatable. If we want MTE to run on production devices, we either (1) optimise out some bits of KASAN (configurable) or (2) we decouple MTE and KASAN completely and add new callbacks in the core code (slab allocator etc.) specific to MTE.

My first choice is (1), unless there is a strong technical argument why it is not possible.

--
Catalin

_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Signature · 3 lines
Derrick McKee
Phone: (703) 957-9362
Email: [email protected]
#56 lore raw

Re: [PATCH 24/35] arm64: mte: Switch GCR_EL1 in kernel entry and exit

In reply to Catalin Marinas
Quoted 14 lines · Catalin Marinas

arch/arm64/kernel/entry.S SYM_FUNC_START(cpu_switch_to) · line 990

Quoted 8 lines · Andrey Konovalov
arch/arm64/kernel/entry.S +1 -0
@@ -957,6 +984,7 @@ SYM_FUNC_START(cpu_switch_to)
      mov     sp, x9
      msr     sp_el0, x1
      ptrauth_keys_install_kernel x1, x8, x9, x10
+     mte_restore_gcr 1, x1, x8, x9
      scs_save x0, x8
      scs_load x1, x8
      ret

Since we set GCR_EL1 on exception entry and return, why is this needed? We don't have a per-kernel thread GCR_EL1, it's global to all threads, so I think cpu_switch_to() should not be touched.

Dropping this line from the diff leads to many false-positives... I'll leave this to Vincenzo.

maintainer
#57 lore raw

Re: [PATCH 24/35] arm64: mte: Switch GCR_EL1 in kernel entry and exit

Quoted 17 lines · Andrey Konovalov
Quoted 14 lines · Catalin Marinas

arch/arm64/kernel/entry.S SYM_FUNC_START(cpu_switch_to) · line 990

Quoted 8 lines · Andrey Konovalov
arch/arm64/kernel/entry.S +1 -0
@@ -957,6 +984,7 @@ SYM_FUNC_START(cpu_switch_to)
      mov     sp, x9
      msr     sp_el0, x1
      ptrauth_keys_install_kernel x1, x8, x9, x10
+     mte_restore_gcr 1, x1, x8, x9
      scs_save x0, x8
      scs_load x1, x8
      ret

Since we set GCR_EL1 on exception entry and return, why is this needed? We don't have a per-kernel thread GCR_EL1, it's global to all threads, so I think cpu_switch_to() should not be touched.

Quoted 2 lines

Dropping this line from the diff leads to many false-positives... I'll leave this to Vincenzo.

I wouldn't expect this to have any effect but maybe the mte_thread_switch() code still touches GCR_EL1 (it does this in the user-space support, Vincenzo's patches should move that to exception entry/return).

Signature · 1 line
Catalin
#58 lore raw

PATCH 25/35 kasan: introduce CONFIG_KASAN_HW_TAGS

In reply to Andrey Konovalov

This patch adds a configuration option for a new KASAN mode called hardware tag-based KASAN. This mode uses the memory tagging approach like the software tag-based mode, but relies on arm64 Memory Tagging Extension feature for tag management and access checking.

---
 lib/Kconfig.kasan | 46 ++++++++++++++++++++++++++++++++--------------
 1 file changed, 32 insertions(+), 14 deletions(-)
lib/Kconfig.kasan +32 -14
index e500c18cbe79..0d4160ce5ee8 100644
@@ -6,7 +6,10 @@ config HAVE_ARCH_KASAN
 config HAVE_ARCH_KASAN_SW_TAGS
 	bool
 
-config	HAVE_ARCH_KASAN_VMALLOC
+config HAVE_ARCH_KASAN_HW_TAGS
+	bool
+
+config HAVE_ARCH_KASAN_VMALLOC
 	bool
 
 config CC_HAS_KASAN_GENERIC
@@ -20,10 +23,11 @@ config CC_HAS_WORKING_NOSANITIZE_ADDRESS
 
 menuconfig KASAN
 	bool "KASAN: runtime memory debugger"
-	depends on (HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC) || \
-		   (HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS)
+	depends on (((HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC) || \
+		     (HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS)) && \
+		    CC_HAS_WORKING_NOSANITIZE_ADDRESS) || \
+		   HAVE_ARCH_KASAN_HW_TAGS
 	depends on (SLUB && SYSFS) || (SLAB && !DEBUG_SLAB)
-	depends on CC_HAS_WORKING_NOSANITIZE_ADDRESS
 	select SLUB_DEBUG if SLUB
 	select CONSTRUCTORS
 	select STACKDEPOT
@@ -38,13 +42,18 @@ choice
 	prompt "KASAN mode"
 	default KASAN_GENERIC
 	help
-	  KASAN has two modes: generic KASAN (similar to userspace ASan,
-	  x86_64/arm64/xtensa, enabled with CONFIG_KASAN_GENERIC) and
-	  software tag-based KASAN (a version based on software memory
-	  tagging, arm64 only, similar to userspace HWASan, enabled with
-	  CONFIG_KASAN_SW_TAGS).
+	  KASAN has three modes:
+	  1. generic KASAN (similar to userspace ASan,
+	     x86_64/arm64/xtensa, enabled with CONFIG_KASAN_GENERIC),
+	  2. software tag-based KASAN (arm64 only, based on software
+	     memory tagging (similar to userspace HWASan), enabled with
+	     CONFIG_KASAN_SW_TAGS), and
+	  3. hardware tag-based KASAN (arm64-only, based hardware
+	     memory tagging (MTE), enabled with CONFIG_KASAN_HW_TAGS).
+
+	  All KASAN modes are strictly debugging features.
 
-	  Both generic and tag-based KASAN are strictly debugging features.
+	  For better error detection enable CONFIG_STACKTRACE.
 
 config KASAN_GENERIC
 	bool "Generic mode"
@@ -61,8 +70,6 @@ config KASAN_GENERIC
 	  and introduces an overhead of ~x1.5 for the rest of the allocations.
 	  The performance slowdown is ~x3.
 
-	  For better error detection enable CONFIG_STACKTRACE.
-
 	  Currently CONFIG_KASAN_GENERIC doesn't work with CONFIG_DEBUG_SLAB
 	  (the resulting kernel does not boot).
 
@@ -83,15 +90,25 @@ config KASAN_SW_TAGS
 	  casting and comparison, as it embeds tags into the top byte of each
 	  pointer.
 
-	  For better error detection enable CONFIG_STACKTRACE.
-
 	  Currently CONFIG_KASAN_SW_TAGS doesn't work with CONFIG_DEBUG_SLAB
 	  (the resulting kernel does not boot).
 
+config KASAN_HW_TAGS
+	bool "Hardware tag-based mode"
+	depends on HAVE_ARCH_KASAN_HW_TAGS
+	depends on SLUB
+	help
+	  Enables hardware tag-based KASAN mode.
+
+	  This mode requires both Memory Tagging Extension and Top Byte Ignore
+	  support by the CPU and therefore is only supported for modern arm64
+	  CPUs (MTE added in ARMv8.5 ISA).
+
 endchoice
 
 choice
 	prompt "Instrumentation type"
+	depends on KASAN_GENERIC || KASAN_SW_TAGS
 	default KASAN_OUTLINE
 
 config KASAN_OUTLINE
@@ -115,6 +132,7 @@ endchoice
 
 config KASAN_STACK_ENABLE
 	bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
+	depends on KASAN_GENERIC || KASAN_SW_TAGS
 	help
 	  The LLVM stack address sanitizer has a know problem that
 	  causes excessive stack usage in a lot of functions, see
Signature · 1 line
2.28.0.220.ged08abb693-goog
#59 lore raw

Re: [PATCH 25/35] kasan: introduce CONFIG_KASAN_HW_TAGS

Hi Andrey,

Review

Quoted 11 lines · Andrey Konovalov
(quoted diff) +11 -0
+config·KASAN_HW_TAGS
+» bool·"Hardware·tag-based·mode"
+» depends·on·HAVE_ARCH_KASAN_HW_TAGS
+» depends·on·SLUB
+» help
+» ··Enables·hardware·tag-based·KASAN·mode.
+
+» ··This·mode·requires·both·Memory·Tagging·Extension·and·Top·Byte·Ignore
+» ··support·by·the·CPU·and·therefore·is·only·supported·for·modern·arm64
+» ··CPUs·(MTE·added·in·ARMv8.5·ISA).
+

I do not thing we should make KASAN_HW_TAGS MTE specific especially because it is in the common code (e.g. SPARC ADI might want to implement it in future).

Probably would be better to provide some indirection in the generic code an implement the MTE backend entirely in arch code.

Thoughts?

Signature · 2 lines
Regards,
Vincenzo
#60 lore raw

Re: [PATCH 25/35] kasan: introduce CONFIG_KASAN_HW_TAGS

Quoted 19 lines · Vincenzo Frascino

Hi Andrey,

Review

Quoted 11 lines · Andrey Konovalov
(quoted diff) +11 -0
+config·KASAN_HW_TAGS
+» bool·"Hardware·tag-based·mode"
+» depends·on·HAVE_ARCH_KASAN_HW_TAGS
+» depends·on·SLUB
+» help
+» ··Enables·hardware·tag-based·KASAN·mode.
+
+» ··This·mode·requires·both·Memory·Tagging·Extension·and·Top·Byte·Ignore
+» ··support·by·the·CPU·and·therefore·is·only·supported·for·modern·arm64
+» ··CPUs·(MTE·added·in·ARMv8.5·ISA).
+

I do not thing we should make KASAN_HW_TAGS MTE specific especially because it is in the common code (e.g. SPARC ADI might want to implement it in future).

Quoted 4 lines

Probably would be better to provide some indirection in the generic code an implement the MTE backend entirely in arch code.

Thoughts?

I think we can reword the help text to say that it enables tag-based KASAN mode that is backed by the hardware in general, and mention that this is currently only implemented for arm64 through MTE. I don't think it makes sense to provide a common arch interface at this point to keep the code simpler. We can do that when (and if) another hardware backend is added.

#61 lore raw

PATCH 26/35 kasan, arm64: Enable TBI EL1

In reply to Andrey Konovalov

From: Vincenzo Frascino <[email protected]>

Hardware tag-based KASAN relies on Memory Tagging Extension (MTE) that is built on top of the Top Byte Ignore (TBI) feature.

Enable in-kernel TBI when CONFIG_KASAN_HW_TAGS is turned on by enabling the TCR_TBI1 bit in proc.S.

---
 arch/arm64/mm/proc.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/mm/proc.S +1 -1
index 152d74f2cc9c..6880ddaa5144 100644
@@ -38,7 +38,7 @@
 /* PTWs cacheable, inner/outer WBWA */
 #define TCR_CACHE_FLAGS	TCR_IRGN_WBWA | TCR_ORGN_WBWA
 
-#ifdef CONFIG_KASAN_SW_TAGS
+#if defined(CONFIG_KASAN_SW_TAGS) || defined(CONFIG_KASAN_HW_TAGS)
 #define TCR_KASAN_FLAGS TCR_TBI1
 #else
 #define TCR_KASAN_FLAGS 0
Signature · 1 line
2.28.0.220.ged08abb693-goog
maintainer
#62 lore raw

Re: [PATCH 26/35] kasan, arm64: Enable TBI EL1

arch/arm64/mm/proc.S line 44

Quoted 13 lines · Andrey Konovalov
arch/arm64/mm/proc.S +1 -1
index 152d74f2cc9c..6880ddaa5144 100644
@@ -38,7 +38,7 @@
 /* PTWs cacheable, inner/outer WBWA */
 #define TCR_CACHE_FLAGS	TCR_IRGN_WBWA | TCR_ORGN_WBWA
 
-#ifdef CONFIG_KASAN_SW_TAGS
+#if defined(CONFIG_KASAN_SW_TAGS) || defined(CONFIG_KASAN_HW_TAGS)
 #define TCR_KASAN_FLAGS TCR_TBI1
 #else
 #define TCR_KASAN_FLAGS 0

I prefer to turn TBI1 on only if MTE is present. So on top of the v8 user series, just do this in __cpu_setup.

Signature · 1 line
Catalin
#63 lore raw

Re: [PATCH 26/35] kasan, arm64: Enable TBI EL1

Quoted 9 lines · Catalin Marinas
Quoted 8 lines · Andrey Konovalov
arch/arm64/mm/proc.S +0 -0
index 152d74f2cc9c..6880ddaa5144 100644
@@ -38,7 +38,7 @@
 /* PTWs cacheable, inner/outer WBWA */
 #define TCR_CACHE_FLAGS	TCR_IRGN_WBWA | TCR_ORGN_WBWA
 
Quoted 9 lines

arch/arm64/mm/proc.S line 44

Quoted 5 lines
arch/arm64/mm/proc.S +1 -1
-#ifdef CONFIG_KASAN_SW_TAGS
+#if defined(CONFIG_KASAN_SW_TAGS) || defined(CONFIG_KASAN_HW_TAGS)
 #define TCR_KASAN_FLAGS TCR_TBI1
 #else
 #define TCR_KASAN_FLAGS 0

I prefer to turn TBI1 on only if MTE is present. So on top of the v8 user series, just do this in __cpu_setup.

Not sure I understand... Enabling TBI1 only if MTE is present would break KASAN_SW_TAGS which is based on TBI1 but not on MTE.

Signature · 2 lines
Regards,
Vincenzo
maintainer
#64 lore raw

Re: [PATCH 26/35] kasan, arm64: Enable TBI EL1

Quoted 19 lines · Vincenzo Frascino
Quoted 9 lines · Catalin Marinas
Quoted 8 lines · Andrey Konovalov
arch/arm64/mm/proc.S +0 -0
index 152d74f2cc9c..6880ddaa5144 100644
@@ -38,7 +38,7 @@
 /* PTWs cacheable, inner/outer WBWA */
 #define TCR_CACHE_FLAGS	TCR_IRGN_WBWA | TCR_ORGN_WBWA
 
Quoted 8 lines

arch/arm64/mm/proc.S line 44

Quoted 5 lines
arch/arm64/mm/proc.S +1 -1
-#ifdef CONFIG_KASAN_SW_TAGS
+#if defined(CONFIG_KASAN_SW_TAGS) || defined(CONFIG_KASAN_HW_TAGS)
 #define TCR_KASAN_FLAGS TCR_TBI1
 #else
 #define TCR_KASAN_FLAGS 0

I prefer to turn TBI1 on only if MTE is present. So on top of the v8 user series, just do this in __cpu_setup.

Quoted 2 lines

Not sure I understand... Enabling TBI1 only if MTE is present would break KASAN_SW_TAGS which is based on TBI1 but not on MTE.

You keep the KASAN_SW_TAGS as above but for HW_TAGS, only set TBI1 later in __cpu_setup().

Signature · 1 line
Catalin
#65 lore raw

Re: [PATCH 26/35] kasan, arm64: Enable TBI EL1

Quoted 20 lines · Catalin Marinas
Quoted 19 lines · Vincenzo Frascino
Quoted 17 lines · Catalin Marinas

arch/arm64/mm/proc.S line 44

Quoted 13 lines · Andrey Konovalov
arch/arm64/mm/proc.S +1 -1
index 152d74f2cc9c..6880ddaa5144 100644
@@ -38,7 +38,7 @@
 /* PTWs cacheable, inner/outer WBWA */
 #define TCR_CACHE_FLAGS	TCR_IRGN_WBWA | TCR_ORGN_WBWA
 
-#ifdef CONFIG_KASAN_SW_TAGS
+#if defined(CONFIG_KASAN_SW_TAGS) || defined(CONFIG_KASAN_HW_TAGS)
 #define TCR_KASAN_FLAGS TCR_TBI1
 #else
 #define TCR_KASAN_FLAGS 0

I prefer to turn TBI1 on only if MTE is present. So on top of the v8 user series, just do this in __cpu_setup.

Quoted 6 lines
Quoted 2 lines

Not sure I understand... Enabling TBI1 only if MTE is present would break KASAN_SW_TAGS which is based on TBI1 but not on MTE.

You keep the KASAN_SW_TAGS as above but for HW_TAGS, only set TBI1 later in __cpu_setup().

Ok, sounds good.

Signature · 2 lines
Regards,
Vincenzo
#66 lore raw

Re: [PATCH 26/35] kasan, arm64: Enable TBI EL1

Quoted 24 lines · Vincenzo Frascino
Quoted 20 lines · Catalin Marinas
Quoted 19 lines · Vincenzo Frascino
Quoted 17 lines · Catalin Marinas

arch/arm64/mm/proc.S line 44

Quoted 13 lines · Andrey Konovalov
arch/arm64/mm/proc.S +1 -1
index 152d74f2cc9c..6880ddaa5144 100644
@@ -38,7 +38,7 @@
 /* PTWs cacheable, inner/outer WBWA */
 #define TCR_CACHE_FLAGS   TCR_IRGN_WBWA | TCR_ORGN_WBWA
 
-#ifdef CONFIG_KASAN_SW_TAGS
+#if defined(CONFIG_KASAN_SW_TAGS) || defined(CONFIG_KASAN_HW_TAGS)
 #define TCR_KASAN_FLAGS TCR_TBI1
 #else
 #define TCR_KASAN_FLAGS 0

I prefer to turn TBI1 on only if MTE is present. So on top of the v8 user series, just do this in __cpu_setup.

Quoted 8 lines
Quoted 6 lines
Quoted 2 lines

Not sure I understand... Enabling TBI1 only if MTE is present would break KASAN_SW_TAGS which is based on TBI1 but not on MTE.

You keep the KASAN_SW_TAGS as above but for HW_TAGS, only set TBI1 later in __cpu_setup().

Ok, sounds good.

Sounds good to me too.

Vincenzo, could you take care of Catalin's comments on your (arm64) patches, do the rebase onto user mte v8, and share it with me? I'll work on KASAN changes in the meantime, and then integrate everything together for v2.

Perhaps the best way to test only the arm64 part is writing a simple module that causes an MTE fault. (At least that's what I did when I was testing core in-kernel MTE patches separately.) Or reuse this series, all KASAN patches should rebase cleanly on top of the latest mainline.

#67 lore raw

Re: [PATCH 26/35] kasan, arm64: Enable TBI EL1

Hi Andrey,

Quoted 33 lines · Andrey Konovalov
Quoted 31 lines · Vincenzo Frascino
Quoted 26 lines · Catalin Marinas
Quoted 19 lines · Vincenzo Frascino
Quoted 9 lines · Catalin Marinas
Quoted 8 lines · Andrey Konovalov
arch/arm64/mm/proc.S +0 -0
index 152d74f2cc9c..6880ddaa5144 100644
@@ -38,7 +38,7 @@
 /* PTWs cacheable, inner/outer WBWA */
 #define TCR_CACHE_FLAGS   TCR_IRGN_WBWA | TCR_ORGN_WBWA
 
Quoted 8 lines

arch/arm64/mm/proc.S line 44

Quoted 5 lines
arch/arm64/mm/proc.S +1 -1
-#ifdef CONFIG_KASAN_SW_TAGS
+#if defined(CONFIG_KASAN_SW_TAGS) || defined(CONFIG_KASAN_HW_TAGS)
 #define TCR_KASAN_FLAGS TCR_TBI1
 #else
 #define TCR_KASAN_FLAGS 0

I prefer to turn TBI1 on only if MTE is present. So on top of the v8 user series, just do this in __cpu_setup.

Quoted 2 lines

Not sure I understand... Enabling TBI1 only if MTE is present would break KASAN_SW_TAGS which is based on TBI1 but not on MTE.

You keep the KASAN_SW_TAGS as above but for HW_TAGS, only set TBI1 later in __cpu_setup().

Quoted 9 lines
Quoted 1 line

Ok, sounds good.

Sounds good to me too.

Vincenzo, could you take care of Catalin's comments on your (arm64) patches, do the rebase onto user mte v8, and share it with me? I'll work on KASAN changes in the meantime, and then integrate everything together for v2.

I am happy to do that. I will be on holiday though from this Saturday till the September, 9. After that I will start the rebasing.

Quoted 6 lines

Perhaps the best way to test only the arm64 part is writing a simple module that causes an MTE fault. (At least that's what I did when I was testing core in-kernel MTE patches separately.) Or reuse this series, all KASAN patches should rebase cleanly on top of the latest mainline.

I can reuse the patches as they are, unless they require changes when I start rebasing. In such a case to not duplicate the work I will scale back to use a simple module.

Signature · 2 lines
Regards,
Vincenzo
#68 lore raw

Re: [PATCH 26/35] kasan, arm64: Enable TBI EL1

Quoted 41 lines · Vincenzo Frascino

Hi Andrey,

Quoted 37 lines · Andrey Konovalov
Quoted 24 lines · Vincenzo Frascino
Quoted 20 lines · Catalin Marinas
Quoted 19 lines · Vincenzo Frascino
Quoted 17 lines · Catalin Marinas

arch/arm64/mm/proc.S line 44

Quoted 13 lines · Andrey Konovalov
arch/arm64/mm/proc.S +1 -1
index 152d74f2cc9c..6880ddaa5144 100644
@@ -38,7 +38,7 @@
 /* PTWs cacheable, inner/outer WBWA */
 #define TCR_CACHE_FLAGS   TCR_IRGN_WBWA | TCR_ORGN_WBWA
 
-#ifdef CONFIG_KASAN_SW_TAGS
+#if defined(CONFIG_KASAN_SW_TAGS) || defined(CONFIG_KASAN_HW_TAGS)
 #define TCR_KASAN_FLAGS TCR_TBI1
 #else
 #define TCR_KASAN_FLAGS 0

I prefer to turn TBI1 on only if MTE is present. So on top of the v8 user series, just do this in __cpu_setup.

Quoted 8 lines
Quoted 6 lines
Quoted 2 lines

Not sure I understand... Enabling TBI1 only if MTE is present would break KASAN_SW_TAGS which is based on TBI1 but not on MTE.

You keep the KASAN_SW_TAGS as above but for HW_TAGS, only set TBI1 later in __cpu_setup().

Ok, sounds good.

Sounds good to me too.

Quoted 8 lines
Quoted 5 lines

Vincenzo, could you take care of Catalin's comments on your (arm64) patches, do the rebase onto user mte v8, and share it with me? I'll work on KASAN changes in the meantime, and then integrate everything together for v2.

I am happy to do that. I will be on holiday though from this Saturday till the September, 9. After that I will start the rebasing.

Ah, OK. I'll see if I can do the rebase and fix some of Catalin's comments myself then. I'll let you know the current status once you're back.

Quoted 15 lines
Quoted 7 lines

Perhaps the best way to test only the arm64 part is writing a simple module that causes an MTE fault. (At least that's what I did when I was testing core in-kernel MTE patches separately.) Or reuse this series, all KASAN patches should rebase cleanly on top of the latest mainline.

I can reuse the patches as they are, unless they require changes when I start rebasing. In such a case to not duplicate the work I will scale back to use a simple module.

--
Regards,
Vincenzo

#69 lore raw

Re: [PATCH 26/35] kasan, arm64: Enable TBI EL1

In reply to Catalin Marinas
Quoted 10 lines · Catalin Marinas
Quoted 8 lines · Andrey Konovalov
arch/arm64/mm/proc.S +0 -0
index 152d74f2cc9c..6880ddaa5144 100644
@@ -38,7 +38,7 @@
 /* PTWs cacheable, inner/outer WBWA */
 #define TCR_CACHE_FLAGS      TCR_IRGN_WBWA | TCR_ORGN_WBWA
 
Quoted 8 lines

arch/arm64/mm/proc.S line 44

Quoted 5 lines
arch/arm64/mm/proc.S +1 -1
-#ifdef CONFIG_KASAN_SW_TAGS
+#if defined(CONFIG_KASAN_SW_TAGS) || defined(CONFIG_KASAN_HW_TAGS)
 #define TCR_KASAN_FLAGS TCR_TBI1
 #else
 #define TCR_KASAN_FLAGS 0

I prefer to turn TBI1 on only if MTE is present. So on top of the v8 user series, just do this in __cpu_setup.

Started working on this, but realized that I don't understand what exactly is suggested here. TCR_KASAN_FLAGS are used in __cpu_setup(), so this already happens in __cpu_setup().

Do you mean that TBI1 should be enabled when CONFIG_ARM64_MTE is enabled, but CONFIG_KASAN_HW_TAGS is disabled?

maintainer
#70 lore raw

Re: [PATCH 26/35] kasan, arm64: Enable TBI EL1

Quoted 21 lines · Andrey Konovalov
Quoted 10 lines · Catalin Marinas
Quoted 8 lines · Andrey Konovalov
arch/arm64/mm/proc.S +0 -0
index 152d74f2cc9c..6880ddaa5144 100644
@@ -38,7 +38,7 @@
 /* PTWs cacheable, inner/outer WBWA */
 #define TCR_CACHE_FLAGS      TCR_IRGN_WBWA | TCR_ORGN_WBWA
 
Quoted 8 lines

arch/arm64/mm/proc.S line 44

Quoted 5 lines
arch/arm64/mm/proc.S +1 -1
-#ifdef CONFIG_KASAN_SW_TAGS
+#if defined(CONFIG_KASAN_SW_TAGS) || defined(CONFIG_KASAN_HW_TAGS)
 #define TCR_KASAN_FLAGS TCR_TBI1
 #else
 #define TCR_KASAN_FLAGS 0

I prefer to turn TBI1 on only if MTE is present. So on top of the v8 user series, just do this in __cpu_setup.

Quoted 6 lines

Started working on this, but realized that I don't understand what exactly is suggested here. TCR_KASAN_FLAGS are used in __cpu_setup(), so this already happens in __cpu_setup().

Do you mean that TBI1 should be enabled when CONFIG_ARM64_MTE is enabled, but CONFIG_KASAN_HW_TAGS is disabled?

What I meant is that we should turn TBI1 only when the MTE is present in hardware (and the ARM64_MTE option is on). But I probably missed the way MTE is used with KASAN.

So what happens if CONFIG_KASAN_HW_TAGS and CONFIG_ARM64_MTE are both on but the hardware does not support MTE? Does KASAN still generate tagged pointers? If yes, then the current patch is fine, we should always set TBI1.

Signature · 1 line
Catalin
#71 lore raw

Re: [PATCH 26/35] kasan, arm64: Enable TBI EL1

Quoted 30 lines · Catalin Marinas
Quoted 21 lines · Andrey Konovalov
Quoted 10 lines · Catalin Marinas
Quoted 8 lines · Andrey Konovalov
arch/arm64/mm/proc.S +0 -0
index 152d74f2cc9c..6880ddaa5144 100644
@@ -38,7 +38,7 @@
 /* PTWs cacheable, inner/outer WBWA */
 #define TCR_CACHE_FLAGS      TCR_IRGN_WBWA | TCR_ORGN_WBWA
 
Quoted 8 lines

arch/arm64/mm/proc.S line 44

Quoted 5 lines
arch/arm64/mm/proc.S +1 -1
-#ifdef CONFIG_KASAN_SW_TAGS
+#if defined(CONFIG_KASAN_SW_TAGS) || defined(CONFIG_KASAN_HW_TAGS)
 #define TCR_KASAN_FLAGS TCR_TBI1
 #else
 #define TCR_KASAN_FLAGS 0

I prefer to turn TBI1 on only if MTE is present. So on top of the v8 user series, just do this in __cpu_setup.

Quoted 6 lines

Started working on this, but realized that I don't understand what exactly is suggested here. TCR_KASAN_FLAGS are used in __cpu_setup(), so this already happens in __cpu_setup().

Do you mean that TBI1 should be enabled when CONFIG_ARM64_MTE is enabled, but CONFIG_KASAN_HW_TAGS is disabled?

Quoted 8 lines

What I meant is that we should turn TBI1 only when the MTE is present in hardware (and the ARM64_MTE option is on). But I probably missed the way MTE is used with KASAN.

So what happens if CONFIG_KASAN_HW_TAGS and CONFIG_ARM64_MTE are both on but the hardware does not support MTE? Does KASAN still generate tagged pointers? If yes, then the current patch is fine, we should always set TBI1.

No, the tag is always 0xFF when MTE is not supported.

Should we then only enable TBI1 if system_supports_mte() or something like that?

maintainer
#72 lore raw

Re: [PATCH 26/35] kasan, arm64: Enable TBI EL1

Quoted 38 lines · Andrey Konovalov
Quoted 28 lines · Catalin Marinas
Quoted 20 lines · Andrey Konovalov
Quoted 9 lines · Catalin Marinas
Quoted 8 lines · Andrey Konovalov
arch/arm64/mm/proc.S +0 -0
index 152d74f2cc9c..6880ddaa5144 100644
@@ -38,7 +38,7 @@
 /* PTWs cacheable, inner/outer WBWA */
 #define TCR_CACHE_FLAGS      TCR_IRGN_WBWA | TCR_ORGN_WBWA
 
Quoted 8 lines

arch/arm64/mm/proc.S line 44

Quoted 5 lines
arch/arm64/mm/proc.S +1 -1
-#ifdef CONFIG_KASAN_SW_TAGS
+#if defined(CONFIG_KASAN_SW_TAGS) || defined(CONFIG_KASAN_HW_TAGS)
 #define TCR_KASAN_FLAGS TCR_TBI1
 #else
 #define TCR_KASAN_FLAGS 0

I prefer to turn TBI1 on only if MTE is present. So on top of the v8 user series, just do this in __cpu_setup.

Quoted 6 lines

Started working on this, but realized that I don't understand what exactly is suggested here. TCR_KASAN_FLAGS are used in __cpu_setup(), so this already happens in __cpu_setup().

Do you mean that TBI1 should be enabled when CONFIG_ARM64_MTE is enabled, but CONFIG_KASAN_HW_TAGS is disabled?

Quoted 8 lines

What I meant is that we should turn TBI1 only when the MTE is present in hardware (and the ARM64_MTE option is on). But I probably missed the way MTE is used with KASAN.

So what happens if CONFIG_KASAN_HW_TAGS and CONFIG_ARM64_MTE are both on but the hardware does not support MTE? Does KASAN still generate tagged pointers? If yes, then the current patch is fine, we should always set TBI1.

Quoted 4 lines

No, the tag is always 0xFF when MTE is not supported.

Should we then only enable TBI1 if system_supports_mte() or something like that?

You could add it do this block in __cpu_setup:

https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/tree/arch/arm64/mm/proc.S?h=for-next/mte#n429

It needs a few changes to have "mov_q x10, TCR_..." before the MTE check so that you can add the TBI1 bit in there.

system_supports_mte() would be called too late, you want this set before the MMU is turned on.

Signature · 1 line
Catalin
#73 lore raw

PATCH 27/35 kasan, arm64: align allocations for HW_TAGS

In reply to Andrey Konovalov

Hardware tag-based KASAN uses the memory tagging approach, which requires all allocations to be aligned to the memory granule size. Align the allocations to MTE_GRANULE_SIZE via ARCH_SLAB_MINALIGN when CONFIG_KASAN_HW_TAGS is enabled.

---
 arch/arm64/include/asm/cache.h | 3 +++
 1 file changed, 3 insertions(+)
arch/arm64/include/asm/cache.h +3 -0
index a4d1b5f771f6..b8a0cae38470 100644
@@ -6,6 +6,7 @@
 #define __ASM_CACHE_H
 
 #include <asm/cputype.h>
+#include <asm/mte_asm.h>
 
 #define CTR_L1IP_SHIFT		14
 #define CTR_L1IP_MASK		3
@@ -50,6 +51,8 @@
 
 #ifdef CONFIG_KASAN_SW_TAGS
 #define ARCH_SLAB_MINALIGN	(1ULL << KASAN_SHADOW_SCALE_SHIFT)
+#elif defined(CONFIG_KASAN_HW_TAGS)
+#define ARCH_SLAB_MINALIGN	MTE_GRANULE_SIZE
 #endif
 
 #ifndef __ASSEMBLY__
Signature · 1 line
2.28.0.220.ged08abb693-goog
#74 lore raw

PATCH 28/35 kasan: define KASAN_GRANULE_SIZE for HW_TAGS

In reply to Andrey Konovalov

Hardware tag-based KASAN has granules of MTE_GRANULE_SIZE. Define KASAN_GRANULE_SIZE to MTE_GRANULE_SIZE for CONFIG_KASAN_HW_TAGS.

---
 mm/kasan/kasan.h | 6 ++++++
 1 file changed, 6 insertions(+)
mm/kasan/kasan.h +6 -0
index 1d3c7c6ce771..4d8e229f8e01 100644
@@ -5,7 +5,13 @@
 #include <linux/kasan.h>
 #include <linux/stackdepot.h>
 
+#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 #define KASAN_GRANULE_SIZE	(1UL << KASAN_SHADOW_SCALE_SHIFT)
+#else
+#include <asm/mte.h>
+#define KASAN_GRANULE_SIZE	(MTE_GRANULE_SIZE)
+#endif
+
 #define KASAN_GRANULE_MASK	(KASAN_GRANULE_SIZE - 1)
 
 #define KASAN_TAG_KERNEL	0xFF /* native kernel pointers tag */
Signature · 1 line
2.28.0.220.ged08abb693-goog
maintainer
#75 lore raw

Re: [PATCH 28/35] kasan: define KASAN_GRANULE_SIZE for HW_TAGS

Quoted 13 lines · Andrey Konovalov

Hardware tag-based KASAN has granules of MTE_GRANULE_SIZE. Define KASAN_GRANULE_SIZE to MTE_GRANULE_SIZE for CONFIG_KASAN_HW_TAGS.

---
 mm/kasan/kasan.h | 6 ++++++
 1 file changed, 6 insertions(+)
mm/kasan/kasan.h +0 -0
index 1d3c7c6ce771..4d8e229f8e01 100644

mm/kasan/kasan.h line 11

Quoted 7 lines
mm/kasan/kasan.h +3 -0
@@ -5,7 +5,13 @@
 #include <linux/kasan.h>
 #include <linux/stackdepot.h>
 
+#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 #define KASAN_GRANULE_SIZE	(1UL << KASAN_SHADOW_SCALE_SHIFT)
+#else
+#include <asm/mte.h>

You could only include the new asm/mte-def.h file (currently mte_asm.h).

Quoted 9 lines
mm/kasan/kasan.h +3 -0
+#define KASAN_GRANULE_SIZE	(MTE_GRANULE_SIZE)
+#endif
+
 #define KASAN_GRANULE_MASK	(KASAN_GRANULE_SIZE - 1)
 
 #define KASAN_TAG_KERNEL	0xFF /* native kernel pointers tag */
Signature · 1 line
2.28.0.220.ged08abb693-goog
Signature · 1 line
Catalin
#76 lore raw

Re: [PATCH 28/35] kasan: define KASAN_GRANULE_SIZE for HW_TAGS

Quoted 17 lines · Catalin Marinas
Quoted 16 lines · Andrey Konovalov

Hardware tag-based KASAN has granules of MTE_GRANULE_SIZE. Define KASAN_GRANULE_SIZE to MTE_GRANULE_SIZE for CONFIG_KASAN_HW_TAGS.

---
 mm/kasan/kasan.h | 6 ++++++
 1 file changed, 6 insertions(+)
mm/kasan/kasan.h +0 -0
index 1d3c7c6ce771..4d8e229f8e01 100644
@@ -5,7 +5,13 @@
 #include <linux/kasan.h>
 #include <linux/stackdepot.h>
 
Quoted 7 lines

mm/kasan/kasan.h line 11

Quoted 4 lines
mm/kasan/kasan.h +3 -0
+#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 #define KASAN_GRANULE_SIZE	(1UL << KASAN_SHADOW_SCALE_SHIFT)
+#else
+#include <asm/mte.h>

You could only include the new asm/mte-def.h file (currently mte_asm.h).

Agreed, we should only include asm/mte-def.h here since after the suggested modification will be sufficient for the purpose.

Quoted 10 lines
Quoted 9 lines
mm/kasan/kasan.h +3 -0
+#define KASAN_GRANULE_SIZE	(MTE_GRANULE_SIZE)
+#endif
+
 #define KASAN_GRANULE_MASK	(KASAN_GRANULE_SIZE - 1)
 
 #define KASAN_TAG_KERNEL	0xFF /* native kernel pointers tag */
Signature · 1 line
2.28.0.220.ged08abb693-goog
Signature · 2 lines
Regards,
Vincenzo
#77 lore raw

Re: [PATCH 28/35] kasan: define KASAN_GRANULE_SIZE for HW_TAGS

Quoted 29 lines · Vincenzo Frascino
Quoted 17 lines · Catalin Marinas
Quoted 16 lines · Andrey Konovalov

Hardware tag-based KASAN has granules of MTE_GRANULE_SIZE. Define KASAN_GRANULE_SIZE to MTE_GRANULE_SIZE for CONFIG_KASAN_HW_TAGS.

---
 mm/kasan/kasan.h | 6 ++++++
 1 file changed, 6 insertions(+)
mm/kasan/kasan.h +0 -0
index 1d3c7c6ce771..4d8e229f8e01 100644
@@ -5,7 +5,13 @@
 #include <linux/kasan.h>
 #include <linux/stackdepot.h>
 
Quoted 7 lines

mm/kasan/kasan.h line 11

Quoted 4 lines
mm/kasan/kasan.h +3 -0
+#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 #define KASAN_GRANULE_SIZE  (1UL << KASAN_SHADOW_SCALE_SHIFT)
+#else
+#include <asm/mte.h>

You could only include the new asm/mte-def.h file (currently mte_asm.h).

Quoted 2 lines

Agreed, we should only include asm/mte-def.h here since after the suggested modification will be sufficient for the purpose.

Will do in v2.

Quoted 15 lines
Quoted 11 lines
Quoted 10 lines
mm/kasan/kasan.h +3 -1
+#define KASAN_GRANULE_SIZE  (MTE_GRANULE_SIZE)
+#endif
+
 #define KASAN_GRANULE_MASK  (KASAN_GRANULE_SIZE - 1)
 
 #define KASAN_TAG_KERNEL    0xFF /* native kernel pointers tag */
--

2.28.0.220.ged08abb693-goog

--
Regards,
Vincenzo

#78 lore raw

PATCH 29/35 kasan, x86, s390: update undef CONFIG_KASAN

In reply to Andrey Konovalov

With the intoduction of hardware tag-based KASAN some kernel checks of this kind:

ifdef CONFIG_KASAN

will be updated to:

  if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)

x86 and s390 use a trick to #undef CONFIG_KASAN for some of the code that isn't linked with KASAN runtime and shouldn't have any KASAN annotations.

Also #undef CONFIG_KASAN_GENERIC with CONFIG_KASAN.

---
 arch/s390/boot/string.c         | 1 +
 arch/x86/boot/compressed/misc.h | 1 +
 2 files changed, 2 insertions(+)
arch/s390/boot/string.c +1 -0
index b11e8108773a..faccb33b462c 100644
@@ -3,6 +3,7 @@
 #include <linux/kernel.h>
 #include <linux/errno.h>
 #undef CONFIG_KASAN
+#undef CONFIG_KASAN_GENERIC
 #include "../lib/string.c"
 
 int strncmp(const char *cs, const char *ct, size_t count)
arch/x86/boot/compressed/misc.h +1 -0
index 726e264410ff..2ac973983a8e 100644
@@ -12,6 +12,7 @@
 #undef CONFIG_PARAVIRT_XXL
 #undef CONFIG_PARAVIRT_SPINLOCKS
 #undef CONFIG_KASAN
+#undef CONFIG_KASAN_GENERIC
 
 /* cpu_feature_enabled() cannot be used this early */
 #define USE_EARLY_PGTABLE_L5
Signature · 1 line
2.28.0.220.ged08abb693-goog
#79 lore raw

PATCH 30/35 kasan, arm64: expand CONFIG_KASAN checks

In reply to Andrey Konovalov

Some #ifdef CONFIG_KASAN checks are only relevant for software KASAN modes (either related to shadow memory or compiler instrumentation). Expand those into CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS.

---
 arch/arm64/Kconfig                 |  2 +-
 arch/arm64/Makefile                |  2 +-
 arch/arm64/include/asm/assembler.h |  2 +-
 arch/arm64/include/asm/memory.h    |  2 +-
 arch/arm64/include/asm/string.h    |  5 +++--
 arch/arm64/kernel/head.S           |  2 +-
 arch/arm64/kernel/image-vars.h     |  2 +-
 arch/arm64/mm/dump.c               |  6 +++---
 include/linux/kasan-checks.h       |  2 +-
 include/linux/kasan.h              |  7 ++++---
 include/linux/moduleloader.h       |  3 ++-
 include/linux/string.h             |  2 +-
 mm/ptdump.c                        | 13 ++++++++-----
 scripts/Makefile.lib               |  2 ++
 14 files changed, 30 insertions(+), 22 deletions(-)
arch/arm64/Kconfig +1 -1
index 32ceff21acc1..70a7880d5145 100644
@@ -320,7 +320,7 @@ config BROKEN_GAS_INST
 
 config KASAN_SHADOW_OFFSET
 	hex
-	depends on KASAN
+	depends on KASAN_GENERIC || KASAN_SW_TAGS
 	default 0xdfffa00000000000 if (ARM64_VA_BITS_48 || ARM64_VA_BITS_52) && !KASAN_SW_TAGS
 	default 0xdfffd00000000000 if ARM64_VA_BITS_47 && !KASAN_SW_TAGS
 	default 0xdffffe8000000000 if ARM64_VA_BITS_42 && !KASAN_SW_TAGS
arch/arm64/Makefile +1 -1
index a0d94d063fa8..89df029a3cff 100644
@@ -125,7 +125,7 @@ TEXT_OFFSET := 0x0
 
 ifeq ($(CONFIG_KASAN_SW_TAGS), y)
 KASAN_SHADOW_SCALE_SHIFT := 4
-else
+else ifeq ($(CONFIG_KASAN_GENERIC), y)
 KASAN_SHADOW_SCALE_SHIFT := 3
 endif
 
arch/arm64/include/asm/assembler.h +1 -1
index 54d181177656..bc9ace1e5f3a 100644
@@ -464,7 +464,7 @@ USER(\label, ic	ivau, \tmp2)			// invalidate I line PoU
 #define NOKPROBE(x)
 #endif
 
-#ifdef CONFIG_KASAN
+#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 #define EXPORT_SYMBOL_NOKASAN(name)
 #else
 #define EXPORT_SYMBOL_NOKASAN(name)	EXPORT_SYMBOL(name)
arch/arm64/include/asm/memory.h +1 -1
index 770535b7ca35..8881849929e3 100644
@@ -75,7 +75,7 @@
  * address space for the shadow region respectively. They can bloat the stack
  * significantly, so double the (minimum) stack size when they are in use.
  */
-#ifdef CONFIG_KASAN
+#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 #define KASAN_SHADOW_OFFSET	_AC(CONFIG_KASAN_SHADOW_OFFSET, UL)
 #define KASAN_SHADOW_END	((UL(1) << (64 - KASAN_SHADOW_SCALE_SHIFT)) \
 					+ KASAN_SHADOW_OFFSET)
arch/arm64/include/asm/string.h +3 -2
index b31e8e87a0db..3a3264ff47b9 100644
@@ -5,7 +5,7 @@
 #ifndef __ASM_STRING_H
 #define __ASM_STRING_H
 
-#ifndef CONFIG_KASAN
+#if !(defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS))
 #define __HAVE_ARCH_STRRCHR
 extern char *strrchr(const char *, int c);
 
@@ -48,7 +48,8 @@ extern void *__memset(void *, int, __kernel_size_t);
 void memcpy_flushcache(void *dst, const void *src, size_t cnt);
 #endif
 
-#if defined(CONFIG_KASAN) && !defined(__SANITIZE_ADDRESS__)
+#if (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) && \
+	!defined(__SANITIZE_ADDRESS__)
 
 /*
  * For files that are not instrumented (e.g. mm/slub.c) we
arch/arm64/kernel/head.S +1 -1
index 037421c66b14..427ded9e68e8 100644
@@ -452,7 +452,7 @@ SYM_FUNC_START_LOCAL(__primary_switched)
 	bl	__pi_memset
 	dsb	ishst				// Make zero page visible to PTW
 
-#ifdef CONFIG_KASAN
+#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 	bl	kasan_early_init
 #endif
 #ifdef CONFIG_RANDOMIZE_BASE
arch/arm64/kernel/image-vars.h +1 -1
index be0a63ffed23..b85372eba2d6 100644
@@ -37,7 +37,7 @@ __efistub_strncmp		= __pi_strncmp;
 __efistub_strrchr		= __pi_strrchr;
 __efistub___clean_dcache_area_poc = __pi___clean_dcache_area_poc;
 
-#ifdef CONFIG_KASAN
+#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 __efistub___memcpy		= __pi_memcpy;
 __efistub___memmove		= __pi_memmove;
 __efistub___memset		= __pi_memset;
arch/arm64/mm/dump.c +3 -3
index ba6d1d89f9b2..bf8ddeac5d8f 100644
@@ -29,7 +29,7 @@
 enum address_markers_idx {
 	PAGE_OFFSET_NR = 0,
 	PAGE_END_NR,
-#ifdef CONFIG_KASAN
+#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 	KASAN_START_NR,
 #endif
 };
@@ -37,7 +37,7 @@ enum address_markers_idx {
 static struct addr_marker address_markers[] = {
 	{ PAGE_OFFSET,			"Linear Mapping start" },
 	{ 0 /* PAGE_END */,		"Linear Mapping end" },
-#ifdef CONFIG_KASAN
+#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 	{ 0 /* KASAN_SHADOW_START */,	"Kasan shadow start" },
 	{ KASAN_SHADOW_END,		"Kasan shadow end" },
 #endif
@@ -381,7 +381,7 @@ void ptdump_check_wx(void)
 static int ptdump_init(void)
 {
 	address_markers[PAGE_END_NR].start_address = PAGE_END;
-#ifdef CONFIG_KASAN
+#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 	address_markers[KASAN_START_NR].start_address = KASAN_SHADOW_START;
 #endif
 	ptdump_initialize();
include/linux/kasan-checks.h +1 -1
index ac6aba632f2d..ca5e89fb10d3 100644
@@ -9,7 +9,7 @@
  * even in compilation units that selectively disable KASAN, but must use KASAN
  * to validate access to an address.   Never use these in header files!
  */
-#ifdef CONFIG_KASAN
+#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 bool __kasan_check_read(const volatile void *p, unsigned int size);
 bool __kasan_check_write(const volatile void *p, unsigned int size);
 #else
include/linux/kasan.h +4 -3
index 894f4d9163ee..875bbcedd994 100644
@@ -232,7 +232,8 @@ static inline void kasan_release_vmalloc(unsigned long start,
 
 #endif /* CONFIG_KASAN_VMALLOC */
 
-#if defined(CONFIG_KASAN) && !defined(CONFIG_KASAN_VMALLOC)
+#if (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) && \
+		!defined(CONFIG_KASAN_VMALLOC)
 
 /*
  * These functions provide a special case to support backing module
@@ -242,12 +243,12 @@ static inline void kasan_release_vmalloc(unsigned long start,
 int kasan_module_alloc(void *addr, size_t size);
 void kasan_free_shadow(const struct vm_struct *vm);
 
-#else /* CONFIG_KASAN && !CONFIG_KASAN_VMALLOC */
+#else /* (CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS) && !CONFIG_KASAN_VMALLOC */
 
 static inline int kasan_module_alloc(void *addr, size_t size) { return 0; }
 static inline void kasan_free_shadow(const struct vm_struct *vm) {}
 
-#endif /* CONFIG_KASAN && !CONFIG_KASAN_VMALLOC */
+#endif /* (CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS) && !CONFIG_KASAN_VMALLOC */
 
 #ifdef CONFIG_KASAN_INLINE
 void kasan_non_canonical_hook(unsigned long addr);
include/linux/moduleloader.h +2 -1
index 4fa67a8b2265..9e09d11ffe5b 100644
@@ -96,7 +96,8 @@ void module_arch_cleanup(struct module *mod);
 /* Any cleanup before freeing mod->module_init */
 void module_arch_freeing_init(struct module *mod);
 
-#if defined(CONFIG_KASAN) && !defined(CONFIG_KASAN_VMALLOC)
+#if (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) && \
+		!defined(CONFIG_KASAN_VMALLOC)
 #include <linux/kasan.h>
 #define MODULE_ALIGN (PAGE_SIZE << KASAN_SHADOW_SCALE_SHIFT)
 #else
include/linux/string.h +1 -1
index 9b7a0632e87a..607322616363 100644
@@ -273,7 +273,7 @@ void __write_overflow(void) __compiletime_error("detected write beyond size of o
 
 #if !defined(__NO_FORTIFY) && defined(__OPTIMIZE__) && defined(CONFIG_FORTIFY_SOURCE)
 
-#ifdef CONFIG_KASAN
+#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 extern void *__underlying_memchr(const void *p, int c, __kernel_size_t size) __RENAME(memchr);
 extern int __underlying_memcmp(const void *p, const void *q, __kernel_size_t size) __RENAME(memcmp);
 extern void *__underlying_memcpy(void *p, const void *q, __kernel_size_t size) __RENAME(memcpy);
mm/ptdump.c +8 -5
index ba88ec43ff21..4354c1422d57 100644
@@ -4,7 +4,7 @@
 #include <linux/ptdump.h>
 #include <linux/kasan.h>
 
-#ifdef CONFIG_KASAN
+#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 /*
  * This is an optimization for KASAN=y case. Since all kasan page tables
  * eventually point to the kasan_early_shadow_page we could call note_page()
@@ -31,7 +31,8 @@ static int ptdump_pgd_entry(pgd_t *pgd, unsigned long addr,
 	struct ptdump_state *st = walk->private;
 	pgd_t val = READ_ONCE(*pgd);
 
-#if CONFIG_PGTABLE_LEVELS > 4 && defined(CONFIG_KASAN)
+#if CONFIG_PGTABLE_LEVELS > 4 && \
+		(defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS))
 	if (pgd_page(val) == virt_to_page(lm_alias(kasan_early_shadow_p4d)))
 		return note_kasan_page_table(walk, addr);
 #endif
@@ -51,7 +52,8 @@ static int ptdump_p4d_entry(p4d_t *p4d, unsigned long addr,
 	struct ptdump_state *st = walk->private;
 	p4d_t val = READ_ONCE(*p4d);
 
-#if CONFIG_PGTABLE_LEVELS > 3 && defined(CONFIG_KASAN)
+#if CONFIG_PGTABLE_LEVELS > 3 && \
+		(defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS))
 	if (p4d_page(val) == virt_to_page(lm_alias(kasan_early_shadow_pud)))
 		return note_kasan_page_table(walk, addr);
 #endif
@@ -71,7 +73,8 @@ static int ptdump_pud_entry(pud_t *pud, unsigned long addr,
 	struct ptdump_state *st = walk->private;
 	pud_t val = READ_ONCE(*pud);
 
-#if CONFIG_PGTABLE_LEVELS > 2 && defined(CONFIG_KASAN)
+#if CONFIG_PGTABLE_LEVELS > 2 && \
+		(defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS))
 	if (pud_page(val) == virt_to_page(lm_alias(kasan_early_shadow_pmd)))
 		return note_kasan_page_table(walk, addr);
 #endif
@@ -91,7 +94,7 @@ static int ptdump_pmd_entry(pmd_t *pmd, unsigned long addr,
 	struct ptdump_state *st = walk->private;
 	pmd_t val = READ_ONCE(*pmd);
 
-#if defined(CONFIG_KASAN)
+#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 	if (pmd_page(val) == virt_to_page(lm_alias(kasan_early_shadow_pte)))
 		return note_kasan_page_table(walk, addr);
 #endif
scripts/Makefile.lib +2 -0
index 99ac59c59826..e527d06b9da8 100644
@@ -135,10 +135,12 @@ endif
 # we don't want to check (depends on variables KASAN_SANITIZE_obj.o, KASAN_SANITIZE)
 #
 ifeq ($(CONFIG_KASAN),y)
+ifneq ($(CONFIG_KASAN_HW_TAGS),y)
 _c_flags += $(if $(patsubst n%,, \
 		$(KASAN_SANITIZE_$(basetarget).o)$(KASAN_SANITIZE)y), \
 		$(CFLAGS_KASAN), $(CFLAGS_KASAN_NOSANITIZE))
 endif
+endif
 
 ifeq ($(CONFIG_UBSAN),y)
 _c_flags += $(if $(patsubst n%,, \
Signature · 1 line
2.28.0.220.ged08abb693-goog
#80 lore raw

PATCH 31/35 kasan, arm64: implement HW_TAGS runtime

In reply to Andrey Konovalov

Provide implementation of KASAN functions required for the hardware tag-based mode. Those include core functions for memory and pointer tagging (mte.c) and bug reporting (report_mte.c). Also adapt common KASAN code to support the new mode.

---
 arch/arm64/include/asm/memory.h   |  4 +-
 arch/arm64/kernel/setup.c         |  1 -
 include/linux/kasan.h             |  6 +--
 include/linux/mm.h                |  2 +-
 include/linux/page-flags-layout.h |  2 +-
 mm/kasan/Makefile                 |  5 ++
 mm/kasan/common.c                 | 14 +++---
 mm/kasan/kasan.h                  | 17 +++++--
 mm/kasan/mte.c                    | 76 +++++++++++++++++++++++++++++++
 mm/kasan/report_mte.c             | 47 +++++++++++++++++++
 mm/kasan/shadow.c                 |  2 +-
 11 files changed, 158 insertions(+), 18 deletions(-)
 create mode 100644 mm/kasan/mte.c
 create mode 100644 mm/kasan/report_mte.c
arch/arm64/include/asm/memory.h +2 -2
index 8881849929e3..433341acf3f3 100644
@@ -214,7 +214,7 @@ static inline unsigned long kaslr_offset(void)
 	(__force __typeof__(addr))__addr;				\
 })
 
-#ifdef CONFIG_KASAN_SW_TAGS
+#if defined(CONFIG_KASAN_SW_TAGS) || defined(CONFIG_KASAN_HW_TAGS)
 #define __tag_shifted(tag)	((u64)(tag) << 56)
 #define __tag_reset(addr)	__untagged_addr(addr)
 #define __tag_get(addr)		(__u8)((u64)(addr) >> 56)
@@ -222,7 +222,7 @@ static inline unsigned long kaslr_offset(void)
 #define __tag_shifted(tag)	0UL
 #define __tag_reset(addr)	(addr)
 #define __tag_get(addr)		0
-#endif /* CONFIG_KASAN_SW_TAGS */
+#endif /* CONFIG_KASAN_SW_TAGS || CONFIG_KASAN_HW_TAGS */
 
 static inline const void *__tag_set(const void *addr, u8 tag)
 {
arch/arm64/kernel/setup.c +0 -1
index 575da075a2b9..4bee6e70eef4 100644
@@ -352,7 +352,6 @@ void __init __no_sanitize_address setup_arch(char **cmdline_p)
 	smp_init_cpus();
 	smp_build_mpidr_hash();
 
-	/* Init percpu seeds for random tags after cpus are set up. */
 	kasan_init_tags();
 
 #ifdef CONFIG_ARM64_SW_TTBR0_PAN
include/linux/kasan.h +3 -3
index 875bbcedd994..613c9d38eee5 100644
@@ -184,7 +184,7 @@ static inline void kasan_record_aux_stack(void *ptr) {}
 
 #endif /* CONFIG_KASAN_GENERIC */
 
-#ifdef CONFIG_KASAN_SW_TAGS
+#if defined(CONFIG_KASAN_SW_TAGS) || defined(CONFIG_KASAN_HW_TAGS)
 
 void kasan_init_tags(void);
 
@@ -193,7 +193,7 @@ void *kasan_reset_tag(const void *addr);
 bool kasan_report(unsigned long addr, size_t size,
 		bool is_write, unsigned long ip);
 
-#else /* CONFIG_KASAN_SW_TAGS */
+#else /* CONFIG_KASAN_SW_TAGS || CONFIG_KASAN_HW_TAGS */
 
 static inline void kasan_init_tags(void) { }
 
@@ -202,7 +202,7 @@ static inline void *kasan_reset_tag(const void *addr)
 	return (void *)addr;
 }
 
-#endif /* CONFIG_KASAN_SW_TAGS */
+#endif /* CONFIG_KASAN_SW_TAGS || CONFIG_KASAN_HW_TAGS*/
 
 #ifdef CONFIG_KASAN_VMALLOC
 
include/linux/mm.h +1 -1
index 65cbbfaa739b..94581f82c1b3 100644
@@ -1395,7 +1395,7 @@ static inline bool cpupid_match_pid(struct task_struct *task, int cpupid)
 }
 #endif /* CONFIG_NUMA_BALANCING */
 
-#ifdef CONFIG_KASAN_SW_TAGS
+#if defined(CONFIG_KASAN_SW_TAGS) || defined(CONFIG_KASAN_HW_TAGS)
 static inline u8 page_kasan_tag(const struct page *page)
 {
 	return (page->flags >> KASAN_TAG_PGSHIFT) & KASAN_TAG_MASK;
include/linux/page-flags-layout.h +1 -1
index 71283739ffd2..75945732a58b 100644
@@ -77,7 +77,7 @@
 #define LAST_CPUPID_SHIFT 0
 #endif
 
-#ifdef CONFIG_KASAN_SW_TAGS
+#if defined(CONFIG_KASAN_SW_TAGS) || defined(CONFIG_KASAN_HW_TAGS)
 #define KASAN_TAG_WIDTH 8
 #else
 #define KASAN_TAG_WIDTH 0
mm/kasan/Makefile +5 -0
index 007c824f6f43..182095c6af28 100644
@@ -10,9 +10,11 @@ CFLAGS_REMOVE_init.o = $(CC_FLAGS_FTRACE)
 CFLAGS_REMOVE_quarantine.o = $(CC_FLAGS_FTRACE)
 CFLAGS_REMOVE_report.o = $(CC_FLAGS_FTRACE)
 CFLAGS_REMOVE_report_generic.o = $(CC_FLAGS_FTRACE)
+CFLAGS_REMOVE_report_mte.o = $(CC_FLAGS_FTRACE)
 CFLAGS_REMOVE_report_tags.o = $(CC_FLAGS_FTRACE)
 CFLAGS_REMOVE_shadow.o = $(CC_FLAGS_FTRACE)
 CFLAGS_REMOVE_tags.o = $(CC_FLAGS_FTRACE)
+CFLAGS_REMOVE_mte.o = $(CC_FLAGS_FTRACE)
 
 # Function splitter causes unnecessary splits in __asan_load1/__asan_store1
 # see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63533
@@ -27,10 +29,13 @@ CFLAGS_init.o := $(CC_FLAGS_KASAN_RUNTIME)
 CFLAGS_quarantine.o := $(CC_FLAGS_KASAN_RUNTIME)
 CFLAGS_report.o := $(CC_FLAGS_KASAN_RUNTIME)
 CFLAGS_report_generic.o := $(CC_FLAGS_KASAN_RUNTIME)
+CFLAGS_report_mte.o := $(CC_FLAGS_KASAN_RUNTIME)
 CFLAGS_report_tags.o := $(CC_FLAGS_KASAN_RUNTIME)
 CFLAGS_shadow.o := $(CC_FLAGS_KASAN_RUNTIME)
 CFLAGS_tags.o := $(CC_FLAGS_KASAN_RUNTIME)
+CFLAGS_mte.o := $(CC_FLAGS_KASAN_RUNTIME)
 
 obj-$(CONFIG_KASAN) := common.o report.o
 obj-$(CONFIG_KASAN_GENERIC) += init.o generic.o report_generic.o shadow.o quarantine.o
 obj-$(CONFIG_KASAN_SW_TAGS) += init.o report_tags.o shadow.o tags.o
+obj-$(CONFIG_KASAN_HW_TAGS) += mte.o report_mte.o
mm/kasan/common.c +8 -6
index 41c7f1105eaa..412a23d1546b 100644
@@ -118,7 +118,7 @@ void kasan_free_pages(struct page *page, unsigned int order)
  */
 static inline unsigned int optimal_redzone(unsigned int object_size)
 {
-	if (IS_ENABLED(CONFIG_KASAN_SW_TAGS))
+	if (!IS_ENABLED(CONFIG_KASAN_GENERIC))
 		return 0;
 
 	return
@@ -183,14 +183,14 @@ size_t kasan_metadata_size(struct kmem_cache *cache)
 struct kasan_alloc_meta *get_alloc_info(struct kmem_cache *cache,
 					const void *object)
 {
-	return (void *)object + cache->kasan_info.alloc_meta_offset;
+	return (void *)reset_tag(object) + cache->kasan_info.alloc_meta_offset;
 }
 
 struct kasan_free_meta *get_free_info(struct kmem_cache *cache,
 				      const void *object)
 {
 	BUILD_BUG_ON(sizeof(struct kasan_free_meta) > 32);
-	return (void *)object + cache->kasan_info.free_meta_offset;
+	return (void *)reset_tag(object) + cache->kasan_info.free_meta_offset;
 }
 
 void kasan_poison_slab(struct page *page)
@@ -272,7 +272,8 @@ void * __must_check kasan_init_slab_obj(struct kmem_cache *cache,
 	alloc_info = get_alloc_info(cache, object);
 	__memset(alloc_info, 0, sizeof(*alloc_info));
 
-	if (IS_ENABLED(CONFIG_KASAN_SW_TAGS))
+	if (IS_ENABLED(CONFIG_KASAN_SW_TAGS) ||
+			IS_ENABLED(CONFIG_KASAN_HW_TAGS))
 		object = set_tag(object,
 				assign_tag(cache, object, true, false));
 
@@ -342,10 +343,11 @@ static void *__kasan_kmalloc(struct kmem_cache *cache, const void *object,
 	redzone_end = round_up((unsigned long)object + cache->object_size,
 				KASAN_GRANULE_SIZE);
 
-	if (IS_ENABLED(CONFIG_KASAN_SW_TAGS))
+	if (IS_ENABLED(CONFIG_KASAN_SW_TAGS) ||
+			IS_ENABLED(CONFIG_KASAN_HW_TAGS))
 		tag = assign_tag(cache, object, false, keep_tag);
 
-	/* Tag is ignored in set_tag without CONFIG_KASAN_SW_TAGS */
+	/* Tag is ignored in set_tag without CONFIG_KASAN_SW/HW_TAGS */
 	kasan_unpoison_memory(set_tag(object, tag), size);
 	kasan_poison_memory((void *)redzone_start, redzone_end - redzone_start,
 		KASAN_KMALLOC_REDZONE);
mm/kasan/kasan.h +14 -3
index 4d8e229f8e01..bc56cf8b9c48 100644
@@ -152,6 +152,10 @@ struct kasan_alloc_meta *get_alloc_info(struct kmem_cache *cache,
 struct kasan_free_meta *get_free_info(struct kmem_cache *cache,
 					const void *object);
 
+void kasan_poison_memory(const void *address, size_t size, u8 value);
+
+#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
+
 static inline const void *kasan_shadow_to_mem(const void *shadow_addr)
 {
 	return (void *)(((unsigned long)shadow_addr - KASAN_SHADOW_OFFSET)
@@ -163,8 +167,6 @@ static inline bool addr_has_metadata(const void *addr)
 	return (addr >= kasan_shadow_to_mem((void *)KASAN_SHADOW_START));
 }
 
-void kasan_poison_memory(const void *address, size_t size, u8 value);
-
 /**
  * check_memory_region - Check memory region, and report if invalid access.
  * @addr: the accessed address
@@ -176,6 +178,15 @@ void kasan_poison_memory(const void *address, size_t size, u8 value);
 bool check_memory_region(unsigned long addr, size_t size, bool write,
 				unsigned long ret_ip);
 
+#else /* CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS */
+
+static inline bool addr_has_metadata(const void *addr)
+{
+	return true;
+}
+
+#endif /* CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS */
+
 bool check_invalid_free(void *addr);
 
 void *find_first_bad_addr(void *addr, size_t size);
@@ -212,7 +223,7 @@ static inline void quarantine_reduce(void) { }
 static inline void quarantine_remove_cache(struct kmem_cache *cache) { }
 #endif
 
-#ifdef CONFIG_KASAN_SW_TAGS
+#if defined(CONFIG_KASAN_SW_TAGS) || defined(CONFIG_KASAN_HW_TAGS)
 
 void print_tags(u8 addr_tag, const void *addr);
 
mm/kasan/mte.c new file +76 -0

76 lines not on this page · raw message

mm/kasan/report_mte.c new file +47 -0

47 lines not on this page · raw message

mm/kasan/shadow.c +1 -1
index 4888084ecdfc..ca69726adf8f 100644
@@ -111,7 +111,7 @@ void kasan_unpoison_memory(const void *address, size_t size)
 
 		if (IS_ENABLED(CONFIG_KASAN_SW_TAGS))
 			*shadow = tag;
-		else
+		else /* CONFIG_KASAN_GENERIC */
 			*shadow = size & KASAN_GRANULE_MASK;
 	}
 }
Signature · 1 line
2.28.0.220.ged08abb693-goog
maintainer
#81 lore raw

Re: [PATCH 31/35] kasan, arm64: implement HW_TAGS runtime

mm/kasan/mte.c

Quoted 5 lines · Andrey Konovalov
mm/kasan/mte.c new file +0 -0
new file mode 100644
index 000000000000..43b7d74161e5

Since this is an arm64-specific kasan backend, I wonder whether it makes more sense to keep it under arch/arm64 (mte-kasan.c).

mm/kasan/report_mte.c

Quoted 5 lines
mm/kasan/report_mte.c new file +0 -0
new file mode 100644
index 000000000000..dbbf3aaa8798

Same for this one.

Signature · 1 line
Catalin
#82 lore raw

Re: [PATCH 31/35] kasan, arm64: implement HW_TAGS runtime

Quoted 10 lines · Catalin Marinas

mm/kasan/mte.c

Quoted 5 lines · Andrey Konovalov
mm/kasan/mte.c new file +0 -0
new file mode 100644
index 000000000000..43b7d74161e5

Since this is an arm64-specific kasan backend, I wonder whether it makes more sense to keep it under arch/arm64 (mte-kasan.c).

Yes I agree, I had a similar comment in patch 25. I think we should implement the mte backend entirely in arch code because other architectures might want to enable the feature (e.g. Sparc ADI).

Quoted 8 lines

mm/kasan/report_mte.c

Quoted 5 lines
mm/kasan/report_mte.c new file +0 -0
new file mode 100644
index 000000000000..dbbf3aaa8798

Same for this one.

Signature · 2 lines
Regards,
Vincenzo
#83 lore raw

Re: [PATCH 31/35] kasan, arm64: implement HW_TAGS runtime

In reply to Catalin Marinas
Quoted 10 lines · Catalin Marinas

mm/kasan/mte.c

Quoted 5 lines · Andrey Konovalov
mm/kasan/mte.c new file +0 -0
new file mode 100644
index 000000000000..43b7d74161e5

Since this is an arm64-specific kasan backend, I wonder whether it makes more sense to keep it under arch/arm64 (mte-kasan.c).

I'm not sure if we do. I'd rather keep everything together, spreading the implementation around the kernel is inconvenient. We already have software tag-based KASAN implementation (which is also arm64-specific) in the common code. We could, perhaps, rename mte.c into something more generic, with other potential future hardware modes in mind.

Quoted 7 lines

mm/kasan/report_mte.c

Quoted 5 lines
mm/kasan/report_mte.c new file +0 -0
new file mode 100644
index 000000000000..dbbf3aaa8798

Same for this one.

#84 lore raw

PATCH 32/35 kasan, arm64: print report from tag fault handler

In reply to Andrey Konovalov

Add error reporting for hardware tag-based KASAN. When CONFIG_KASAN_HW_TAGS is enabled, print KASAN report from the arm64 tag fault handler.

SAS bits aren't set in ESR for all faults reported in EL1, so it's impossible to find out the size of the access the caused the fault. Adapt KASAN reporting code to handle this case.

---
 arch/arm64/mm/fault.c |  9 +++++++++
 mm/kasan/report.c     | 11 ++++++++---
 2 files changed, 17 insertions(+), 3 deletions(-)
arch/arm64/mm/fault.c +9 -0
index c62c8ba85c0e..cf00b3942564 100644
@@ -14,6 +14,7 @@
 #include <linux/mm.h>
 #include <linux/hardirq.h>
 #include <linux/init.h>
+#include <linux/kasan.h>
 #include <linux/kprobes.h>
 #include <linux/uaccess.h>
 #include <linux/page-flags.h>
@@ -314,11 +315,19 @@ static void report_tag_fault(unsigned long addr, unsigned int esr,
 {
 	bool is_write = ((esr & ESR_ELx_WNR) >> ESR_ELx_WNR_SHIFT) != 0;
 
+#ifdef CONFIG_KASAN_HW_TAGS
+	/*
+	 * SAS bits aren't set for all faults reported in EL1, so we can't
+	 * find out access size.
+	 */
+	kasan_report(addr, 0, is_write, regs->pc);
+#else
 	pr_alert("Memory Tagging Extension Fault in %pS\n", (void *)regs->pc);
 	pr_alert("  %s at address %lx\n", is_write ? "Write" : "Read", addr);
 	pr_alert("  Pointer tag: [%02x], memory tag: [%02x]\n",
 			mte_get_ptr_tag(addr),
 			mte_get_mem_tag((void *)addr));
+#endif
 }
 
 static void __do_kernel_fault(unsigned long addr, unsigned int esr,
mm/kasan/report.c +8 -3
index c904edab33b8..34ef81736d73 100644
@@ -65,9 +65,14 @@ static void print_error_description(struct kasan_access_info *info)
 {
 	pr_err("BUG: KASAN: %s in %pS\n",
 		get_bug_type(info), (void *)info->ip);
-	pr_err("%s of size %zu at addr %px by task %s/%d\n",
-		info->is_write ? "Write" : "Read", info->access_size,
-		info->access_addr, current->comm, task_pid_nr(current));
+	if (info->access_size)
+		pr_err("%s of size %zu at addr %px by task %s/%d\n",
+			info->is_write ? "Write" : "Read", info->access_size,
+			info->access_addr, current->comm, task_pid_nr(current));
+	else
+		pr_err("%s at addr %px by task %s/%d\n",
+			info->is_write ? "Write" : "Read",
+			info->access_addr, current->comm, task_pid_nr(current));
 }
 
 static DEFINE_SPINLOCK(report_lock);
Signature · 1 line
2.28.0.220.ged08abb693-goog
maintainer
#85 lore raw

Re: [PATCH 32/35] kasan, arm64: print report from tag fault handler

Quoted 20 lines · Andrey Konovalov
arch/arm64/mm/fault.c +5 -0
index c62c8ba85c0e..cf00b3942564 100644
@@ -14,6 +14,7 @@
 #include <linux/mm.h>
 #include <linux/hardirq.h>
 #include <linux/init.h>
+#include <linux/kasan.h>
 #include <linux/kprobes.h>
 #include <linux/uaccess.h>
 #include <linux/page-flags.h>
@@ -314,11 +315,19 @@ static void report_tag_fault(unsigned long addr, unsigned int esr,
 {
 	bool is_write = ((esr & ESR_ELx_WNR) >> ESR_ELx_WNR_SHIFT) != 0;
 
+#ifdef CONFIG_KASAN_HW_TAGS
+	/*
+	 * SAS bits aren't set for all faults reported in EL1, so we can't
+	 * find out access size.

arch/arm64/mm/fault.c static void report_tag_fault(unsigned long addr, unsigned int esr, · line 331

Quoted 10 lines
arch/arm64/mm/fault.c +4 -0
+	 */
+	kasan_report(addr, 0, is_write, regs->pc);
+#else
 	pr_alert("Memory Tagging Extension Fault in %pS\n", (void *)regs->pc);
 	pr_alert("  %s at address %lx\n", is_write ? "Write" : "Read", addr);
 	pr_alert("  Pointer tag: [%02x], memory tag: [%02x]\n",
 			mte_get_ptr_tag(addr),
 			mte_get_mem_tag((void *)addr));
+#endif
 }

More dead code. So what's the point of keeping the pr_alert() introduced earlier? CONFIG_KASAN_HW_TAGS is always on for in-kernel MTE. If MTE is disabled, this function isn't called anyway.

Signature · 1 line
Catalin
#86 lore raw

Re: [PATCH 32/35] kasan, arm64: print report from tag fault handler

Quoted 27 lines · Catalin Marinas
Quoted 26 lines · Andrey Konovalov
arch/arm64/mm/fault.c +8 -0
index c62c8ba85c0e..cf00b3942564 100644
@@ -14,6 +14,7 @@
 #include <linux/mm.h>
 #include <linux/hardirq.h>
 #include <linux/init.h>
+#include <linux/kasan.h>
 #include <linux/kprobes.h>
 #include <linux/uaccess.h>
 #include <linux/page-flags.h>
@@ -314,11 +315,19 @@ static void report_tag_fault(unsigned long addr, unsigned int esr,
 {
 	bool is_write = ((esr & ESR_ELx_WNR) >> ESR_ELx_WNR_SHIFT) != 0;
 
+#ifdef CONFIG_KASAN_HW_TAGS
+	/*
+	 * SAS bits aren't set for all faults reported in EL1, so we can't
+	 * find out access size.
+	 */
+	kasan_report(addr, 0, is_write, regs->pc);
+#else
 	pr_alert("Memory Tagging Extension Fault in %pS\n", (void *)regs->pc);
 	pr_alert("  %s at address %lx\n", is_write ? "Write" : "Read", addr);
 	pr_alert("  Pointer tag: [%02x], memory tag: [%02x]\n",
Quoted 9 lines

arch/arm64/mm/fault.c static void report_tag_fault(unsigned long addr, unsigned int esr, · line 331

Quoted 4 lines
arch/arm64/mm/fault.c +1 -0
 			mte_get_ptr_tag(addr),
 			mte_get_mem_tag((void *)addr));
+#endif
 }

More dead code. So what's the point of keeping the pr_alert() introduced earlier? CONFIG_KASAN_HW_TAGS is always on for in-kernel MTE. If MTE is disabled, this function isn't called anyway.

I agree we should remove them (togheter with '#ifdef CONFIG_KASAN_HW_TAGS') or integrate them with the kasan code if still meaningful.

Signature · 2 lines
Regards,
Vincenzo
#87 lore raw

Re: [PATCH 32/35] kasan, arm64: print report from tag fault handler

In reply to Catalin Marinas
Quoted 28 lines · Catalin Marinas
Quoted 26 lines · Andrey Konovalov
arch/arm64/mm/fault.c +8 -0
index c62c8ba85c0e..cf00b3942564 100644
@@ -14,6 +14,7 @@
 #include <linux/mm.h>
 #include <linux/hardirq.h>
 #include <linux/init.h>
+#include <linux/kasan.h>
 #include <linux/kprobes.h>
 #include <linux/uaccess.h>
 #include <linux/page-flags.h>
@@ -314,11 +315,19 @@ static void report_tag_fault(unsigned long addr, unsigned int esr,
 {
      bool is_write = ((esr & ESR_ELx_WNR) >> ESR_ELx_WNR_SHIFT) != 0;
 
+#ifdef CONFIG_KASAN_HW_TAGS
+     /*
+      * SAS bits aren't set for all faults reported in EL1, so we can't
+      * find out access size.
+      */
+     kasan_report(addr, 0, is_write, regs->pc);
+#else
      pr_alert("Memory Tagging Extension Fault in %pS\n", (void *)regs->pc);
      pr_alert("  %s at address %lx\n", is_write ? "Write" : "Read", addr);
      pr_alert("  Pointer tag: [%02x], memory tag: [%02x]\n",
Quoted 8 lines

arch/arm64/mm/fault.c static void report_tag_fault(unsigned long addr, unsigned int esr, · line 331

Quoted 4 lines
arch/arm64/mm/fault.c +1 -0
                      mte_get_ptr_tag(addr),
                      mte_get_mem_tag((void *)addr));
+#endif
 }

More dead code. So what's the point of keeping the pr_alert() introduced earlier? CONFIG_KASAN_HW_TAGS is always on for in-kernel MTE. If MTE is disabled, this function isn't called anyway.

I was considering that we can enable in-kernel MTE without enabling CONFIG_KASAN_HW_TAGS, but perhaps this isn't what we want. I'll drop this part in v2, but then we also need to make sure that in-kernel MTE is only enabled when CONFIG_KASAN_HW_TAGS is enabled. Do we need more ifdefs in arm64 patches when we write to MTE-related registers, or does this work as is?

maintainer
#88 lore raw

Re: [PATCH 32/35] kasan, arm64: print report from tag fault handler

Quoted 38 lines · Andrey Konovalov
Quoted 27 lines · Catalin Marinas
Quoted 26 lines · Andrey Konovalov
arch/arm64/mm/fault.c +8 -0
index c62c8ba85c0e..cf00b3942564 100644
@@ -14,6 +14,7 @@
 #include <linux/mm.h>
 #include <linux/hardirq.h>
 #include <linux/init.h>
+#include <linux/kasan.h>
 #include <linux/kprobes.h>
 #include <linux/uaccess.h>
 #include <linux/page-flags.h>
@@ -314,11 +315,19 @@ static void report_tag_fault(unsigned long addr, unsigned int esr,
 {
      bool is_write = ((esr & ESR_ELx_WNR) >> ESR_ELx_WNR_SHIFT) != 0;
 
+#ifdef CONFIG_KASAN_HW_TAGS
+     /*
+      * SAS bits aren't set for all faults reported in EL1, so we can't
+      * find out access size.
+      */
+     kasan_report(addr, 0, is_write, regs->pc);
+#else
      pr_alert("Memory Tagging Extension Fault in %pS\n", (void *)regs->pc);
      pr_alert("  %s at address %lx\n", is_write ? "Write" : "Read", addr);
      pr_alert("  Pointer tag: [%02x], memory tag: [%02x]\n",
Quoted 8 lines

arch/arm64/mm/fault.c static void report_tag_fault(unsigned long addr, unsigned int esr, · line 331

Quoted 4 lines
arch/arm64/mm/fault.c +1 -0
                      mte_get_ptr_tag(addr),
                      mte_get_mem_tag((void *)addr));
+#endif
 }

More dead code. So what's the point of keeping the pr_alert() introduced earlier? CONFIG_KASAN_HW_TAGS is always on for in-kernel MTE. If MTE is disabled, this function isn't called anyway.

Quoted 6 lines

I was considering that we can enable in-kernel MTE without enabling CONFIG_KASAN_HW_TAGS, but perhaps this isn't what we want. I'll drop this part in v2, but then we also need to make sure that in-kernel MTE is only enabled when CONFIG_KASAN_HW_TAGS is enabled. Do we need more ifdefs in arm64 patches when we write to MTE-related registers, or does this work as is?

I think the in-kernel MTE for the time being should only mean CONFIG_KASAN_HW_TAGS, with a dependency on CONFIG_MTE. KASAN carries some additional debugging features but if we can trim it down, we may not need a separate in-kernel MTE option for production systems (maybe a CONFIG_KASAN_HW_TAGS_LITE).

Signature · 1 line
Catalin
#89 lore raw

PATCH 33/35 kasan, slub: reset tags when accessing metadata

In reply to Andrey Konovalov

SLUB allocator accesses metadata for slab objects, that may lie out-of-bounds of the object itself, or be accessed when an object is freed. Handle this for Hardware tag-based KASAN by resetting tags when accessing metadata.

Hardware tag-based KASAN doesn't rely on metadata_access_disable/enable(), and therefore requires resetting tags in the sections of code guarded by those annotations.

---
 mm/page_poison.c |  2 +-
 mm/slub.c        | 25 ++++++++++++++-----------
 2 files changed, 15 insertions(+), 12 deletions(-)
mm/page_poison.c +1 -1
index 34b9181ee5d1..d90d342a391f 100644
@@ -43,7 +43,7 @@ static void poison_page(struct page *page)
 
 	/* KASAN still think the page is in-use, so skip it. */
 	kasan_disable_current();
-	memset(addr, PAGE_POISON, PAGE_SIZE);
+	memset(kasan_reset_tag(addr), PAGE_POISON, PAGE_SIZE);
 	kasan_enable_current();
 	kunmap_atomic(addr);
 }
mm/slub.c +14 -11
index ef303070d175..a786e1cee095 100644
@@ -249,7 +249,7 @@ static inline void *freelist_ptr(const struct kmem_cache *s, void *ptr,
 {
 #ifdef CONFIG_SLAB_FREELIST_HARDENED
 	/*
-	 * When CONFIG_KASAN_SW_TAGS is enabled, ptr_addr might be tagged.
+	 * When CONFIG_KASAN_SW/HW_TAGS is enabled, ptr_addr might be tagged.
 	 * Normally, this doesn't cause any issues, as both set_freepointer()
 	 * and get_freepointer() are called with a pointer with the same tag.
 	 * However, there are some issues with CONFIG_SLUB_DEBUG code. For
@@ -275,6 +275,7 @@ static inline void *freelist_dereference(const struct kmem_cache *s,
 
 static inline void *get_freepointer(struct kmem_cache *s, void *object)
 {
+	object = kasan_reset_tag(object);
 	return freelist_dereference(s, object + s->offset);
 }
 
@@ -304,6 +305,7 @@ static inline void set_freepointer(struct kmem_cache *s, void *object, void *fp)
 	BUG_ON(object == fp); /* naive detection of double free or corruption */
 #endif
 
+	freeptr_addr = (unsigned long)kasan_reset_tag((void *)freeptr_addr);
 	*(void **)freeptr_addr = freelist_ptr(s, fp, freeptr_addr);
 }
 
@@ -546,8 +548,8 @@ static void print_section(char *level, char *text, u8 *addr,
 			  unsigned int length)
 {
 	metadata_access_enable();
-	print_hex_dump(level, text, DUMP_PREFIX_ADDRESS, 16, 1, addr,
-			length, 1);
+	print_hex_dump(level, kasan_reset_tag(text), DUMP_PREFIX_ADDRESS,
+			16, 1, addr, length, 1);
 	metadata_access_disable();
 }
 
@@ -578,7 +580,7 @@ static struct track *get_track(struct kmem_cache *s, void *object,
 
 	p = object + get_info_end(s);
 
-	return p + alloc;
+	return kasan_reset_tag(p + alloc);
 }
 
 static void set_track(struct kmem_cache *s, void *object,
@@ -591,7 +593,8 @@ static void set_track(struct kmem_cache *s, void *object,
 		unsigned int nr_entries;
 
 		metadata_access_enable();
-		nr_entries = stack_trace_save(p->addrs, TRACK_ADDRS_COUNT, 3);
+		nr_entries = stack_trace_save(kasan_reset_tag(p->addrs),
+						TRACK_ADDRS_COUNT, 3);
 		metadata_access_disable();
 
 		if (nr_entries < TRACK_ADDRS_COUNT)
@@ -755,7 +758,7 @@ static __printf(3, 4) void slab_err(struct kmem_cache *s, struct page *page,
 
 static void init_object(struct kmem_cache *s, void *object, u8 val)
 {
-	u8 *p = object;
+	u8 *p = kasan_reset_tag(object);
 
 	if (s->flags & SLAB_RED_ZONE)
 		memset(p - s->red_left_pad, val, s->red_left_pad);
@@ -785,7 +788,7 @@ static int check_bytes_and_report(struct kmem_cache *s, struct page *page,
 	u8 *addr = page_address(page);
 
 	metadata_access_enable();
-	fault = memchr_inv(start, value, bytes);
+	fault = memchr_inv(kasan_reset_tag(start), value, bytes);
 	metadata_access_disable();
 	if (!fault)
 		return 1;
@@ -881,7 +884,7 @@ static int slab_pad_check(struct kmem_cache *s, struct page *page)
 
 	pad = end - remainder;
 	metadata_access_enable();
-	fault = memchr_inv(pad, POISON_INUSE, remainder);
+	fault = memchr_inv(kasan_reset_tag(pad), POISON_INUSE, remainder);
 	metadata_access_disable();
 	if (!fault)
 		return 1;
@@ -1126,7 +1129,7 @@ void setup_page_debug(struct kmem_cache *s, struct page *page, void *addr)
 		return;
 
 	metadata_access_enable();
-	memset(addr, POISON_INUSE, page_size(page));
+	memset(kasan_reset_tag(addr), POISON_INUSE, page_size(page));
 	metadata_access_disable();
 }
 
@@ -2816,10 +2819,10 @@ static __always_inline void *slab_alloc_node(struct kmem_cache *s,
 		stat(s, ALLOC_FASTPATH);
 	}
 
-	maybe_wipe_obj_freeptr(s, object);
+	maybe_wipe_obj_freeptr(s, kasan_reset_tag(object));
 
 	if (unlikely(slab_want_init_on_alloc(gfpflags, s)) && object)
-		memset(object, 0, s->object_size);
+		memset(kasan_reset_tag(object), 0, s->object_size);
 
 	slab_post_alloc_hook(s, gfpflags, 1, &object);
 
Signature · 1 line
2.28.0.220.ged08abb693-goog
#90 lore raw

PATCH 34/35 kasan, arm64: enable CONFIG_KASAN_HW_TAGS

In reply to Andrey Konovalov

Hardware tag-based KASAN is now ready, enable the configuration option.

---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)
arch/arm64/Kconfig +1 -0
index 70a7880d5145..0d95d8391d0f 100644
@@ -131,6 +131,7 @@ config ARM64
 	select HAVE_ARCH_JUMP_LABEL_RELATIVE
 	select HAVE_ARCH_KASAN if !(ARM64_16K_PAGES && ARM64_VA_BITS_48)
 	select HAVE_ARCH_KASAN_SW_TAGS if HAVE_ARCH_KASAN
+	select HAVE_ARCH_KASAN_HW_TAGS if (HAVE_ARCH_KASAN && ARM64_MTE)
 	select HAVE_ARCH_KGDB
 	select HAVE_ARCH_MMAP_RND_BITS
 	select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
Signature · 1 line
2.28.0.220.ged08abb693-goog
#91 lore raw

PATCH 35/35 kasan: add documentation for hardware tag-based mode

In reply to Andrey Konovalov

Add documentation for hardware tag-based KASAN mode and also add some clarifications for software tag-based mode.

---
 Documentation/dev-tools/kasan.rst | 73 +++++++++++++++++++++----------
 1 file changed, 51 insertions(+), 22 deletions(-)
Documentation/dev-tools/kasan.rst +51 -22
index a3030fc6afe5..aeed89d6eaf5 100644
@@ -5,12 +5,14 @@ Overview
 --------
 
 KernelAddressSANitizer (KASAN) is a dynamic memory error detector designed to
-find out-of-bound and use-after-free bugs. KASAN has two modes: generic KASAN
-(similar to userspace ASan) and software tag-based KASAN (similar to userspace
-HWASan).
+find out-of-bound and use-after-free bugs. KASAN has three modes:
+1. generic KASAN (similar to userspace ASan),
+2. software tag-based KASAN (similar to userspace HWASan),
+3. hardware tag-based KASAN (based on hardware memory tagging).
 
-KASAN uses compile-time instrumentation to insert validity checks before every
-memory access, and therefore requires a compiler version that supports that.
+Software KASAN modes (1 and 2) use compile-time instrumentation to insert
+validity checks before every memory access, and therefore require a compiler
+version that supports that.
 
 Generic KASAN is supported in both GCC and Clang. With GCC it requires version
 8.3.0 or later. With Clang it requires version 7.0.0 or later, but detection of
@@ -19,7 +21,7 @@ out-of-bounds accesses for global variables is only supported since Clang 11.
 Tag-based KASAN is only supported in Clang and requires version 7.0.0 or later.
 
 Currently generic KASAN is supported for the x86_64, arm64, xtensa, s390 and
-riscv architectures, and tag-based KASAN is supported only for arm64.
+riscv architectures, and tag-based KASAN modes are supported only for arm64.
 
 Usage
 -----
@@ -28,14 +30,16 @@ To enable KASAN configure kernel with::
 
 	  CONFIG_KASAN = y
 
-and choose between CONFIG_KASAN_GENERIC (to enable generic KASAN) and
-CONFIG_KASAN_SW_TAGS (to enable software tag-based KASAN).
+and choose between CONFIG_KASAN_GENERIC (to enable generic KASAN),
+CONFIG_KASAN_SW_TAGS (to enable software tag-based KASAN), and
+CONFIG_KASAN_HW_TAGS (to enable hardware tag-based KASAN).
 
-You also need to choose between CONFIG_KASAN_OUTLINE and CONFIG_KASAN_INLINE.
-Outline and inline are compiler instrumentation types. The former produces
-smaller binary while the latter is 1.1 - 2 times faster.
+For software modes, you also need to choose between CONFIG_KASAN_OUTLINE and
+CONFIG_KASAN_INLINE. Outline and inline are compiler instrumentation types.
+The former produces smaller binary while the latter is 1.1 - 2 times faster.
 
-Both KASAN modes work with both SLUB and SLAB memory allocators.
+Both software KASAN modes work with both SLUB and SLAB memory allocators,
+hardware tag-based KASAN currently only support SLUB.
 For better bug detection and nicer reporting, enable CONFIG_STACKTRACE.
 
 To augment reports with last allocation and freeing stack of the physical page,
@@ -196,17 +200,20 @@ and the second to last.
 Software tag-based KASAN
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
-Tag-based KASAN uses the Top Byte Ignore (TBI) feature of modern arm64 CPUs to
-store a pointer tag in the top byte of kernel pointers. Like generic KASAN it
-uses shadow memory to store memory tags associated with each 16-byte memory
-cell (therefore it dedicates 1/16th of the kernel memory for shadow memory).
+Software tag-based KASAN uses the Top Byte Ignore (TBI) feature of modern arm64
+CPUs to store a pointer tag in the top byte of kernel pointers. Like generic
+KASAN it uses shadow memory to store memory tags associated with each 16-byte
+memory cell (therefore it dedicates 1/16th of the kernel memory for shadow
+memory).
+
+On each memory allocation software tag-based KASAN generates a random tag, tags
+the allocated memory with this tag, and embeds this tag into the returned
+pointer.
 
-On each memory allocation tag-based KASAN generates a random tag, tags the
-allocated memory with this tag, and embeds this tag into the returned pointer.
 Software tag-based KASAN uses compile-time instrumentation to insert checks
 before each memory access. These checks make sure that tag of the memory that
 is being accessed is equal to tag of the pointer that is used to access this
-memory. In case of a tag mismatch tag-based KASAN prints a bug report.
+memory. In case of a tag mismatch software tag-based KASAN prints a bug report.
 
 Software tag-based KASAN also has two instrumentation modes (outline, that
 emits callbacks to check memory accesses; and inline, that performs the shadow
@@ -215,9 +222,31 @@ simply printed from the function that performs the access check. With inline
 instrumentation a brk instruction is emitted by the compiler, and a dedicated
 brk handler is used to print bug reports.
 
-A potential expansion of this mode is a hardware tag-based mode, which would
-use hardware memory tagging support instead of compiler instrumentation and
-manual shadow memory manipulation.
+Software tag-based KASAN uses 0xFF as a match-all pointer tag (accesses aren't
+checked).
+
+Software tag-based KASAN currently only supports tagging of slab memory.
+
+Hardware tag-based KASAN
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Hardware tag-based KASAN is similar to the software mode in concept, but uses
+hardware memory tagging support instead of compiler instrumentation and
+shadow memory.
+
+Hardware tag-based KASAN is based on both arm64 Memory Tagging Extension (MTE)
+introduced in ARMv8.5 Instruction Set Architecture, and Top Byte Ignore (TBI).
+
+Special arm64 instructions are used to assign memory tags for each allocation.
+Same tags are assigned to pointers to those allocations. On every memory
+access, hardware makes sure that tag of the memory that is being accessed is
+equal to tag of the pointer that is used to access this memory. In case of a
+tag mismatch a fault is generated and a report is printed.
+
+Hardware tag-based KASAN uses 0xFF as a match-all pointer tag (accesses aren't
+checked).
+
+Hardware tag-based KASAN currently only supports tagging of slab memory.
 
 What memory accesses are sanitised by KASAN?
 --------------------------------------------
Signature · 1 line
2.28.0.220.ged08abb693-goog
#92 lore raw

Re: [PATCH 35/35] kasan: add documentation for hardware tag-based mode

Quoted 10 lines · Andrey Konovalov

Add documentation for hardware tag-based KASAN mode and also add some clarifications for software tag-based mode.

---
 Documentation/dev-tools/kasan.rst | 73 +++++++++++++++++++++----------
 1 file changed, 51 insertions(+), 22 deletions(-)
Documentation/dev-tools/kasan.rst +0 -0
index a3030fc6afe5..aeed89d6eaf5 100644

[...]

Documentation/dev-tools/kasan.rst and the second to last. · line 207

Quoted 9 lines
Documentation/dev-tools/kasan.rst +5 -4
-Tag-based KASAN uses the Top Byte Ignore (TBI) feature of modern arm64 CPUs to
-store a pointer tag in the top byte of kernel pointers. Like generic KASAN it
-uses shadow memory to store memory tags associated with each 16-byte memory
-cell (therefore it dedicates 1/16th of the kernel memory for shadow memory).
+Software tag-based KASAN uses the Top Byte Ignore (TBI) feature of modern arm64
+CPUs to store a pointer tag in the top byte of kernel pointers. Like generic
+KASAN it uses shadow memory to store memory tags associated with each 16-byte
+memory cell (therefore it dedicates 1/16th of the kernel memory for shadow
+memory).

It might be helpful to be more specific vs. saying "modern arm64 CPUs". Does the "modern" qualifier suggest not all arm64 CPUs support the feature? (HW tag-based KASAN below is specific, and mentions ARMv8.5.)

Quoted 25 lines
Documentation/dev-tools/kasan.rst +8 -6
+On each memory allocation software tag-based KASAN generates a random tag, tags
+the allocated memory with this tag, and embeds this tag into the returned
+pointer.
 
-On each memory allocation tag-based KASAN generates a random tag, tags the
-allocated memory with this tag, and embeds this tag into the returned pointer.
 Software tag-based KASAN uses compile-time instrumentation to insert checks
 before each memory access. These checks make sure that tag of the memory that
 is being accessed is equal to tag of the pointer that is used to access this
-memory. In case of a tag mismatch tag-based KASAN prints a bug report.
+memory. In case of a tag mismatch software tag-based KASAN prints a bug report.
 
 Software tag-based KASAN also has two instrumentation modes (outline, that
 emits callbacks to check memory accesses; and inline, that performs the shadow
@@ -215,9 +222,31 @@ simply printed from the function that performs the access check. With inline
 instrumentation a brk instruction is emitted by the compiler, and a dedicated
 brk handler is used to print bug reports.
 
-A potential expansion of this mode is a hardware tag-based mode, which would
-use hardware memory tagging support instead of compiler instrumentation and
-manual shadow memory manipulation.
+Software tag-based KASAN uses 0xFF as a match-all pointer tag (accesses aren't
+checked).
+
+Software tag-based KASAN currently only supports tagging of slab memory.

Documentation/dev-tools/kasan.rst simply printed from the function that performs the access check. With inline · line 238

Quoted 10 lines
Documentation/dev-tools/kasan.rst +10 -0
+
+Hardware tag-based KASAN
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Hardware tag-based KASAN is similar to the software mode in concept, but uses
+hardware memory tagging support instead of compiler instrumentation and
+shadow memory.
+
+Hardware tag-based KASAN is based on both arm64 Memory Tagging Extension (MTE)
+introduced in ARMv8.5 Instruction Set Architecture, and Top Byte Ignore (TBI).

Is there anything inherently tying tag-based KASAN to arm64? I guess if some other architecture supports MTE, they just have to touch arch/, right?

You could reword to say that "Hardware tag-based KASAN is currently only supported on the ARM64 architecture.

On the ARM64 architecture, tag-based KASAN is based on both ..."

Thanks,
-- Marco

#93 lore raw

Re: [PATCH 35/35] kasan: add documentation for hardware tag-based mode

Quoted 13 lines · Marco Elver
Quoted 10 lines · Andrey Konovalov

Add documentation for hardware tag-based KASAN mode and also add some clarifications for software tag-based mode.

---
 Documentation/dev-tools/kasan.rst | 73 +++++++++++++++++++++----------
 1 file changed, 51 insertions(+), 22 deletions(-)
Documentation/dev-tools/kasan.rst +0 -0
index a3030fc6afe5..aeed89d6eaf5 100644

[...]

Quoted 13 lines

Documentation/dev-tools/kasan.rst and the second to last. · line 207

Quoted 9 lines
Documentation/dev-tools/kasan.rst +5 -4
-Tag-based KASAN uses the Top Byte Ignore (TBI) feature of modern arm64 CPUs to
-store a pointer tag in the top byte of kernel pointers. Like generic KASAN it
-uses shadow memory to store memory tags associated with each 16-byte memory
-cell (therefore it dedicates 1/16th of the kernel memory for shadow memory).
+Software tag-based KASAN uses the Top Byte Ignore (TBI) feature of modern arm64
+CPUs to store a pointer tag in the top byte of kernel pointers. Like generic
+KASAN it uses shadow memory to store memory tags associated with each 16-byte
+memory cell (therefore it dedicates 1/16th of the kernel memory for shadow
+memory).

It might be helpful to be more specific vs. saying "modern arm64 CPUs". Does the "modern" qualifier suggest not all arm64 CPUs support the feature? (HW tag-based KASAN below is specific, and mentions ARMv8.5.)

Will clarify this in v2.

Quoted 29 lines
Quoted 29 lines
Documentation/dev-tools/kasan.rst +12 -6
+On each memory allocation software tag-based KASAN generates a random tag, tags
+the allocated memory with this tag, and embeds this tag into the returned
+pointer.
 
-On each memory allocation tag-based KASAN generates a random tag, tags the
-allocated memory with this tag, and embeds this tag into the returned pointer.
 Software tag-based KASAN uses compile-time instrumentation to insert checks
 before each memory access. These checks make sure that tag of the memory that
 is being accessed is equal to tag of the pointer that is used to access this
-memory. In case of a tag mismatch tag-based KASAN prints a bug report.
+memory. In case of a tag mismatch software tag-based KASAN prints a bug report.
 
 Software tag-based KASAN also has two instrumentation modes (outline, that
 emits callbacks to check memory accesses; and inline, that performs the shadow
@@ -215,9 +222,31 @@ simply printed from the function that performs the access check. With inline
 instrumentation a brk instruction is emitted by the compiler, and a dedicated
 brk handler is used to print bug reports.
 
-A potential expansion of this mode is a hardware tag-based mode, which would
-use hardware memory tagging support instead of compiler instrumentation and
-manual shadow memory manipulation.
+Software tag-based KASAN uses 0xFF as a match-all pointer tag (accesses aren't
+checked).
+
+Software tag-based KASAN currently only supports tagging of slab memory.
+
+Hardware tag-based KASAN
+~~~~~~~~~~~~~~~~~~~~~~~~
+
Quoted 8 lines

Documentation/dev-tools/kasan.rst simply printed from the function that performs the access check. With inline · line 238

Quoted 6 lines
Documentation/dev-tools/kasan.rst +6 -0
+Hardware tag-based KASAN is similar to the software mode in concept, but uses
+hardware memory tagging support instead of compiler instrumentation and
+shadow memory.
+
+Hardware tag-based KASAN is based on both arm64 Memory Tagging Extension (MTE)
+introduced in ARMv8.5 Instruction Set Architecture, and Top Byte Ignore (TBI).

Is there anything inherently tying tag-based KASAN to arm64?

Not really, the approach is generic and can be used by any arch that supports memory tagging.

Quoted 3 lines

I guess if
some other architecture supports MTE, they just have to touch arch/, right?

For the most part - yes, but maybe adjustments to the generic code will be required. No way to know before one tries to integrate another arch.

Quoted 4 lines

You could reword to say that "Hardware tag-based KASAN is currently only supported on the ARM64 architecture.

On the ARM64 architecture, tag-based KASAN is based on both ..."

Will do in v2, thanks!

#94 lore raw
In reply to Andrey Konovalov
Quoted 4 lines

This patchset adds a new hardware tag-based mode to KASAN [1]. The new mode is similar to the existing software tag-based KASAN, but relies on arm64 Memory Tagging Extension (MTE) [2] to perform memory and pointer tagging (instead of shadow memory and compiler instrumentation).

What does one need to do to enable MTE in the kernel? I am trying to color some kernel module data, but when I call mte_get_mem_tag after calling mte_set_mem_tag_range, I get an invalid value. I have assured that mte_assign_mem_tag_range has been called in mte_set_mem_tag_range, so the initial sanity checks pass. Thanks.

_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

#95 lore raw
Quoted 11 lines · Derrick McKee
Quoted 5 lines

This patchset adds a new hardware tag-based mode to KASAN [1]. The new mode is similar to the existing software tag-based KASAN, but relies on arm64 Memory Tagging Extension (MTE) [2] to perform memory and pointer tagging (instead of shadow memory and compiler instrumentation).

What does one need to do to enable MTE in the kernel? I am trying to color some kernel module data, but when I call mte_get_mem_tag after calling mte_set_mem_tag_range, I get an invalid value. I have assured that mte_assign_mem_tag_range has been called in mte_set_mem_tag_range, so the initial sanity checks pass. Thanks.

Hi Derrick,

One needs to use the latest QEMU master and provide "-machine virt,mte=on -cpu max" arguments to it. I'll add this information into the cover letter for v2.

Thanks!

_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

#96 lore raw
Quoted 3 lines · Andrey Konovalov

One needs to use the latest QEMU master and provide "-machine virt,mte=on -cpu max" arguments to it. I'll add this information into the cover letter for v2.

I am using the latest QEMU as of Sep. 8, and starting the system with virt,mte=on, and I have also checked that the appropriate bits are set in sctlr_el1 and ID_AA64PFR1_EL1. Finally, when I print out the tag immediately before and after mte_assign_mem_tag_range I get the same result.

_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

#97 lore raw
Quoted 6 lines · Derrick McKee
Quoted 3 lines · Andrey Konovalov

One needs to use the latest QEMU master and provide "-machine virt,mte=on -cpu max" arguments to it. I'll add this information into the cover letter for v2.

I am using the latest QEMU as of Sep. 8, and starting the system with virt,mte=on, and I have also checked that the appropriate bits are set in sctlr_el1 and ID_AA64PFR1_EL1. Finally, when I print out the tag immediately before and after mte_assign_mem_tag_range I get the same result.

I should also mention that CONFIG_KASAN_HW_TAGS=n in my configuration, but I have added my own macro to enable my code and added it to the conditional macro in memory.h:224. I have also ensured that mte_init_tags is called from setup_arch. But still the result of the ldg instruction to get the address tag is always 0, despite the desired tag of 2. Perhaps I am missing some other needed setup or configuration?

_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

#98 lore raw
Quoted 13 lines · Derrick McKee
Quoted 10 lines · Derrick McKee
Quoted 3 lines · Andrey Konovalov

One needs to use the latest QEMU master and provide "-machine virt,mte=on -cpu max" arguments to it. I'll add this information into the cover letter for v2.

I am using the latest QEMU as of Sep. 8, and starting the system with virt,mte=on, and I have also checked that the appropriate bits are set in sctlr_el1 and ID_AA64PFR1_EL1. Finally, when I print out the tag immediately before and after mte_assign_mem_tag_range I get the same result.

Quoted 6 lines

I should also mention that CONFIG_KASAN_HW_TAGS=n in my configuration, but I have added my own macro to enable my code and added it to the conditional macro in memory.h:224. I have also ensured that mte_init_tags is called from setup_arch. But still the result of the ldg instruction to get the address tag is always 0, despite the desired tag of 2. Perhaps I am missing some other needed setup or configuration?

Hm, this should work I guess.

Could you try CONFIG_KASAN_HW_TAGS=y and check if that works?

_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

#100 lore raw
Quoted 1 line · Derrick McKee

This seems to work, as the tags change appropriately. So I guess I need to figure out what I am doing differently.  Thanks for the help.

The problem was that the kernel uses the PAGE_KERNEL flag when allocating memory for modules, and the solution was to change that to PAGE_KERNEL_TAGGED. It might be worth adding this new flag to the documentation somewhere.

_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel