kasan: add hardware tag-based mode for arm64
Subsystems (16)
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:
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.cSignature · 1 line
2.28.0.220.ged08abb693-goog
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
@@ -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
PATCH 2/35 kasan: group vmalloc code
In reply to Andrey KonovalovThis 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
@@ -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
PATCH 3/35 kasan: shadow declarations only for software modes
In reply to Andrey KonovalovThis 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
@@ -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
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.
Signed-off-by Andrey Konovalov <[email protected]>--- include/linux/kasan.h | 44 ++++++++++++++++++++++++++----------------- 1 file changed, 27 insertions(+), 17 deletions(-)include/linux/kasan.h +0
-0
[...]
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
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.
Signed-off-by Andrey Konovalov <[email protected]>--- include/linux/kasan.h | 44 ++++++++++++++++++++++++++----------------- 1 file changed, 27 insertions(+), 17 deletions(-)include/linux/kasan.h +0
-0[...]
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!
PATCH 4/35 kasan: rename (un)poison_shadow to (un)poison_memory
In reply to Andrey KonovalovThis 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH 5/35 kasan: rename KASAN_SHADOW_* to KASAN_GRANULE_*
In reply to Andrey KonovalovThis 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH 6/35 kasan: only build init.c for software modes
In reply to Andrey KonovalovThis 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
@@ -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
@@ -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
PATCH 7/35 kasan: split out shadow.c from common.c
In reply to Andrey KonovalovThis 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
@@ -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
PATCH 8/35 kasan: rename generic/tags_report.c files
In reply to Andrey KonovalovRename 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
@@ -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
@@ -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
mm/kasan/report_tags.c renamed from mm/kasan/tags_report.c +0 -0
Signature · 1 line
2.28.0.220.ged08abb693-goog
PATCH 9/35 kasan: don't duplicate config dependencies
In reply to Andrey KonovalovBoth 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
@@ -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
PATCH 10/35 kasan: hide invalid free check implementation
In reply to Andrey KonovalovThis 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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH 11/35 kasan: decode stack frame only with KASAN_STACK_ENABLE
In reply to Andrey KonovalovDecoding 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
@@ -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
PATCH 12/35 kasan, arm64: only init shadow for software modes
In reply to Andrey KonovalovThis 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
@@ -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
@@ -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
PATCH 13/35 kasan, arm64: only use kasan_depth for software modes
In reply to Andrey KonovalovThis 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH 14/35 kasan: rename addr_has_shadow to addr_has_metadata
In reply to Andrey KonovalovThis 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
@@ -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
@@ -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
@@ -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
PATCH 15/35 kasan: rename print_shadow_for_address to print_memory_metadata
In reply to Andrey KonovalovThis 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
@@ -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
PATCH 16/35 kasan: kasan_non_canonical_hook only for software modes
In reply to Andrey KonovalovThis 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
@@ -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
PATCH 17/35 kasan: rename SHADOW layout macros to META
In reply to Andrey KonovalovThis 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
@@ -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 2static 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
PATCH 18/35 kasan: separate metadata_fetch_row for each mode
In reply to Andrey KonovalovThis 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
@@ -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
@@ -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
@@ -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
PATCH 19/35 kasan: don't allow SW_TAGS with ARM64_MTE
In reply to Andrey KonovalovSoftware 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
@@ -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
Catalin Marinas
maintainerRe: [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.
Signed-off-by Andrey Konovalov <[email protected]>--- lib/Kconfig.kasan | 1 + 1 file changed, 1 insertion(+)lib/Kconfig.kasan +0
-0
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
@@ -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
Vincenzo Frascino
reviewerRe: [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.
Signed-off-by Andrey Konovalov <[email protected]>--- lib/Kconfig.kasan | 1 + 1 file changed, 1 insertion(+)lib/Kconfig.kasan +0
-0lib/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_MTEI think that's better as:
arch/arm64/Kconfig +0
-0
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
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.
Signed-off-by Andrey Konovalov <[email protected]>--- lib/Kconfig.kasan | 1 + 1 file changed, 1 insertion(+)lib/Kconfig.kasan +0
-0lib/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_MTEI think that's better as:
arch/arm64/Kconfig +0
-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
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 COMPATI agree with Catalin here, "select
HAVE_ARCH_KASAN_SW_TAGSifHAVE_ARCH_KASAN&& !ARM64_MTE" should be sufficient.
Sounds good, will do in v2, thanks!
PATCH 20/35 arm64: mte: Add in-kernel MTE helpers
In reply to Andrey KonovalovFrom: 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
@@ -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
@@ -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
Catalin Marinas
maintainerRe: [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@@ -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@@ -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@@ -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
Vincenzo Frascino
reviewerRe: [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@@ -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_asmimplies 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@@ -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_ONif 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@@ -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
Catalin Marinas
maintainerRe: [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_ONif 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 beMTE_GRANULE_SIZEalignedQuoted 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
Vincenzo Frascino
reviewerRe: [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_ONif 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 beMTE_GRANULE_SIZEalignedQuoted 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
Re: [PATCH 20/35] arm64: mte: Add in-kernel MTE helpers
In reply to Catalin MarinasQuoted 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@@ -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_asmimplies 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@@ -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_ONif 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@@ -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.
Re: [PATCH 20/35] arm64: mte: Add in-kernel MTE helpers
In reply to Catalin MarinasQuoted 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@@ -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_asmimplies 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@@ -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?
Catalin Marinas
maintainerRe: [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@@ -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_asmimplies 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@@ -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_ifand other similar macros used inarch/arm64/code, is that what you mean? Those seem to always use static conditions, like config values, but here we have a dynamicsystem_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
PATCH 21/35 arm64: mte: Add in-kernel tag fault handler
In reply to Andrey KonovalovFrom: 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
@@ -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
Catalin Marinas
maintainerRe: [PATCH 21/35] arm64: mte: Add in-kernel tag fault handler
Quoted 53 lines · Andrey Konovalov
arch/arm64/mm/fault.c +27
-0@@ -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
-0die_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
Vincenzo Frascino
reviewerRe: [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@@ -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
-0msg ="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
-0die_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 theis_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
Re: [PATCH 21/35] arm64: mte: Add in-kernel tag fault handler
In reply to Catalin MarinasQuoted 81 lines · Catalin Marinas
Quoted 53 lines · Andrey Konovalov
arch/arm64/mm/fault.c +27
-0@@ -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
-0die_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 theis_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.
Catalin Marinas
maintainerRe: [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_faultoption 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
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_faultoption 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
Catalin Marinas
maintainerRe: [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
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
Catalin Marinas
maintainerRe: [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
PATCH 22/35 arm64: mte: Enable in-kernel MTE
In reply to Andrey KonovalovFrom: 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
@@ -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
Catalin Marinas
maintainerRe: [PATCH 22/35] arm64: mte: Enable in-kernel MTE
Quoted 15 lines · Andrey Konovalov
arch/arm64/kernel/cpufeature.c +3
-0@@ -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
Vincenzo Frascino
reviewerRe: [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@@ -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
-0write_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.Sbefore the MMU is initialised. When rebasing, please take this into account.
Thank you for the heads up.
Signature · 2 lines
Regards, Vincenzo
Re: [PATCH 22/35] arm64: mte: Enable in-kernel MTE
In reply to Andrey KonovalovQuoted 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_EL1affects only EL1 in a similar way as TCF0 affects EL0.Signed-off-by Vincenzo Frascino <[email protected]>--- arch/arm64/kernel/cpufeature.c | 6 ++++++ 1 file changed, 6 insertions(+)arch/arm64/kernel/cpufeature.c +6
-1@@ -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?
Catalin Marinas
maintainerRe: [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_EL1affects only EL1 in a similar way as TCF0 affects EL0.Signed-off-by Vincenzo Frascino <[email protected]>--- arch/arm64/kernel/cpufeature.c | 6 ++++++ 1 file changed, 6 insertions(+)arch/arm64/kernel/cpufeature.c +6
-0@@ -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
-1local_flush_tlb_all (); --2.28.0.220.ged08abb693-goog
Should we change this commit to enable in-kernel MTE only if
KASAN_HW_TAGSis 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
PATCH 23/35 arm64: mte: Convert gcr_user into an exclude mask
In reply to Andrey KonovalovFrom: 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
@@ -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
@@ -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
PATCH 24/35 arm64: mte: Switch GCR_EL1 in kernel entry and exit
In reply to Andrey KonovalovFrom: 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
Catalin Marinas
maintainerRe: [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@@ -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
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
Vincenzo Frascino
reviewerRe: [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@@ -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 retSince we set
GCR_EL1on exception entry and return, why is this needed? We don't have a per-kernel threadGCR_EL1, it's global to all threads, so I thinkcpu_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@@ -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
Catalin Marinas
maintainerRe: [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@@ -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_exclin 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
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@@ -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_exclin 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.
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@@ -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_exclin 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_exclis currently initialized inmte_init_tags()and depends on themax_tagvalue dynamically provided to it, so it's not something that can be expressed with a define. In the case of KASAN themax_tagvalue 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.
Catalin Marinas
maintainerRe: [PATCH 24/35] arm64: mte: Switch GCR_EL1 in kernel entry and exit
In reply to Andrey KonovalovQuoted 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@@ -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_exclin 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_exclis currently initialized inmte_init_tags()and depends on themax_tagvalue dynamically provided to it, so it's not something that can be expressed with a define. In the case of KASAN themax_tagvalue 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
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@@ -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_exclin 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_exclis currently initialized inmte_init_tags()and depends on themax_tagvalue dynamically provided to it, so it's not something that can be expressed with a define. In the case of KASAN themax_tagvalue 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]
Re: [PATCH 24/35] arm64: mte: Switch GCR_EL1 in kernel entry and exit
In reply to Catalin MarinasQuoted 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 retSince we set
GCR_EL1on exception entry and return, why is this needed? We don't have a per-kernel threadGCR_EL1, it's global to all threads, so I thinkcpu_switch_to()should not be touched.
Dropping this line from the diff leads to many false-positives... I'll leave this to Vincenzo.
Catalin Marinas
maintainerRe: [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 retSince we set
GCR_EL1on exception entry and return, why is this needed? We don't have a per-kernel threadGCR_EL1, it's global to all threads, so I thinkcpu_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
PATCH 25/35 kasan: introduce CONFIG_KASAN_HW_TAGS
In reply to Andrey KonovalovThis 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
@@ -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
Vincenzo Frascino
reviewerRe: [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
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_TAGSMTE 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.
PATCH 26/35 kasan, arm64: Enable TBI EL1
In reply to Andrey KonovalovFrom: 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
@@ -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
Catalin Marinas
maintainerRe: [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@@ -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
Vincenzo Frascino
reviewerRe: [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@@ -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 0I 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
Catalin Marinas
maintainerRe: [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@@ -38,7 +38,7 @@ /* PTWs cacheable, inner/outer WBWA */ #define TCR_CACHE_FLAGS TCR_IRGN_WBWA | TCR_ORGN_WBWAQuoted 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 0I 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_TAGSwhich 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
Vincenzo Frascino
reviewerRe: [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@@ -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 0I 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_TAGSwhich is based on TBI1 but not on MTE.You keep the
KASAN_SW_TAGSas above but forHW_TAGS, only set TBI1 later in__cpu_setup().
Ok, sounds good.
Signature · 2 lines
Regards, Vincenzo
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@@ -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 0I 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_TAGSwhich is based on TBI1 but not on MTE.You keep the
KASAN_SW_TAGSas above but forHW_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.
Vincenzo Frascino
reviewerRe: [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@@ -38,7 +38,7 @@ /* PTWs cacheable, inner/outer WBWA */ #define TCR_CACHE_FLAGS TCR_IRGN_WBWA | TCR_ORGN_WBWAQuoted 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 0I 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_TAGSwhich is based on TBI1 but not on MTE.You keep the
KASAN_SW_TAGSas above but forHW_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
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@@ -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 0I 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_TAGSwhich is based on TBI1 but not on MTE.You keep the
KASAN_SW_TAGSas above but forHW_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
Re: [PATCH 26/35] kasan, arm64: Enable TBI EL1
In reply to Catalin MarinasQuoted 10 lines · Catalin Marinas
Quoted 8 lines · Andrey Konovalov
arch/arm64/mm/proc.S +0
-0@@ -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 0I 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?
Catalin Marinas
maintainerRe: [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@@ -38,7 +38,7 @@ /* PTWs cacheable, inner/outer WBWA */ #define TCR_CACHE_FLAGS TCR_IRGN_WBWA | TCR_ORGN_WBWAQuoted 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 0I 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_FLAGSare used in__cpu_setup(), so this already happens in__cpu_setup().Do you mean that TBI1 should be enabled when
CONFIG_ARM64_MTEis enabled, butCONFIG_KASAN_HW_TAGSis 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
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@@ -38,7 +38,7 @@ /* PTWs cacheable, inner/outer WBWA */ #define TCR_CACHE_FLAGS TCR_IRGN_WBWA | TCR_ORGN_WBWAQuoted 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 0I 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_FLAGSare used in__cpu_setup(), so this already happens in__cpu_setup().Do you mean that TBI1 should be enabled when
CONFIG_ARM64_MTEis enabled, butCONFIG_KASAN_HW_TAGSis disabled?
Quoted 8 lines
What I meant is that we should turn TBI1 only when the MTE is present in hardware (and the
ARM64_MTEoption is on). But I probably missed the way MTE is used with KASAN.So what happens if
CONFIG_KASAN_HW_TAGSandCONFIG_ARM64_MTEare 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?
Catalin Marinas
maintainerRe: [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@@ -38,7 +38,7 @@ /* PTWs cacheable, inner/outer WBWA */ #define TCR_CACHE_FLAGS TCR_IRGN_WBWA | TCR_ORGN_WBWAQuoted 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 0I 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_FLAGSare used in__cpu_setup(), so this already happens in__cpu_setup().Do you mean that TBI1 should be enabled when
CONFIG_ARM64_MTEis enabled, butCONFIG_KASAN_HW_TAGSis disabled?Quoted 8 lines
What I meant is that we should turn TBI1 only when the MTE is present in hardware (and the
ARM64_MTEoption is on). But I probably missed the way MTE is used with KASAN.So what happens if
CONFIG_KASAN_HW_TAGSandCONFIG_ARM64_MTEare 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
0xFFwhen 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:
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
PATCH 27/35 kasan, arm64: align allocations for HW_TAGS
In reply to Andrey KonovalovHardware 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
@@ -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
PATCH 28/35 kasan: define KASAN_GRANULE_SIZE for HW_TAGS
In reply to Andrey KonovalovHardware 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
@@ -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
Catalin Marinas
maintainerRe: [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. DefineKASAN_GRANULE_SIZEtoMTE_GRANULE_SIZEforCONFIG_KASAN_HW_TAGS.Signed-off-by Andrey Konovalov <[email protected]>--- mm/kasan/kasan.h | 6 ++++++ 1 file changed, 6 insertions(+)mm/kasan/kasan.h +0
-0
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
Vincenzo Frascino
reviewerRe: [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. DefineKASAN_GRANULE_SIZEtoMTE_GRANULE_SIZEforCONFIG_KASAN_HW_TAGS.Signed-off-by Andrey Konovalov <[email protected]>--- mm/kasan/kasan.h | 6 ++++++ 1 file changed, 6 insertions(+)mm/kasan/kasan.h +0
-0@@ -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.hfile (currentlymte_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
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. DefineKASAN_GRANULE_SIZEtoMTE_GRANULE_SIZEforCONFIG_KASAN_HW_TAGS.Signed-off-by Andrey Konovalov <[email protected]>--- mm/kasan/kasan.h | 6 ++++++ 1 file changed, 6 insertions(+)mm/kasan/kasan.h +0
-0@@ -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.hfile (currentlymte_asm.h).
Quoted 2 lines
Agreed, we should only include
asm/mte-def.hhere 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
PATCH 29/35 kasan, x86, s390: update undef CONFIG_KASAN
In reply to Andrey KonovalovWith 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
@@ -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
@@ -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
PATCH 30/35 kasan, arm64: expand CONFIG_KASAN checks
In reply to Andrey KonovalovSome #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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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_STRRCHRextern 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH 31/35 kasan, arm64: implement HW_TAGS runtime
In reply to Andrey KonovalovProvide 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
Catalin Marinas
maintainerRe: [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
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
Same for this one.
Signature · 1 line
Catalin
Vincenzo Frascino
reviewerRe: [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
-0Since 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
-0Same for this one.
Signature · 2 lines
Regards, Vincenzo
Re: [PATCH 31/35] kasan, arm64: implement HW_TAGS runtime
In reply to Catalin MarinasQuoted 10 lines · Catalin Marinas
mm/kasan/mte.c
Quoted 5 lines · Andrey Konovalov
mm/kasan/mte.c new file +0
-0Since 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
-0Same for this one.
PATCH 32/35 kasan, arm64: print report from tag fault handler
In reply to Andrey KonovalovAdd 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
@@ -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
@@ -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
Catalin Marinas
maintainerRe: [PATCH 32/35] kasan, arm64: print report from tag fault handler
Quoted 20 lines · Andrey Konovalov
arch/arm64/mm/fault.c +5
-0@@ -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
Vincenzo Frascino
reviewerRe: [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@@ -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
-0mte_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_TAGSis 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
Re: [PATCH 32/35] kasan, arm64: print report from tag fault handler
In reply to Catalin MarinasQuoted 28 lines · Catalin Marinas
Quoted 26 lines · Andrey Konovalov
arch/arm64/mm/fault.c +8
-0@@ -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
-0mte_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_TAGSis 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?
Catalin Marinas
maintainerRe: [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@@ -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
-0mte_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_TAGSis 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 whenCONFIG_KASAN_HW_TAGSis 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
PATCH 33/35 kasan, slub: reset tags when accessing metadata
In reply to Andrey KonovalovSLUB 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
@@ -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
@@ -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
PATCH 34/35 kasan, arm64: enable CONFIG_KASAN_HW_TAGS
In reply to Andrey KonovalovHardware tag-based KASAN is now ready, enable the configuration option.
--- arch/arm64/Kconfig | 1 + 1 file changed, 1 insertion(+)
arch/arm64/Kconfig +1 -0
@@ -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
PATCH 35/35 kasan: add documentation for hardware tag-based mode
In reply to Andrey KonovalovAdd 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
@@ -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
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.
Signed-off-by Andrey Konovalov <[email protected]>--- Documentation/dev-tools/kasan.rst | 73 +++++++++++++++++++++---------- 1 file changed, 51 insertions(+), 22 deletions(-)Documentation/dev-tools/kasan.rst +0
-0
[...]
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
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.
Signed-off-by Andrey Konovalov <[email protected]>--- Documentation/dev-tools/kasan.rst | 73 +++++++++++++++++++++---------- 1 file changed, 51 insertions(+), 22 deletions(-)Documentation/dev-tools/kasan.rst +0
-0[...]
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 toucharch/, 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!
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
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_tagafter callingmte_set_mem_tag_range, I get an invalid value. I have assured thatmte_assign_mem_tag_rangehas been called inmte_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
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
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_el1andID_AA64PFR1_EL1. Finally, when I print out the tag immediately before and aftermte_assign_mem_tag_rangeI 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
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_el1andID_AA64PFR1_EL1. Finally, when I print out the tag immediately before and aftermte_assign_mem_tag_rangeI get the same result.
Quoted 6 lines
I should also mention that
CONFIG_KASAN_HW_TAGS=nin 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 thatmte_init_tagsis called fromsetup_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
Quoted 3 lines · Andrey Konovalov
Hm, this should work I guess.
Could you try
CONFIG_KASAN_HW_TAGS=yand check if that works?
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.
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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