Skip to contentSkip to conversation

kasan: support stack instrumentation for tag-based mode

PATCH In review Andrey Konovalov 3 participants 9 messages Aug 4, 2020

Subsystems (9)
lore
Share & tools
lore
#0 lore raw

v2 cover kasan: support stack instrumentation for tag-based mode

This goes on top of Walter's patch titled "kasan: fix KASAN unit tests for tag-based KASAN" (already in mm tree).

Bugzilla link: https://bugzilla.kernel.org/show_bug.cgi?id=203497

Thanks to Walter Wu for debugging and testing.

Changes v1 -> v2:
- Add efi patch to undefined reference to `efi_enter_virtual_mode'.
- Reorder attributes for start_kernel().

Andrey Konovalov (5):
kasan: don't tag stacks allocated with pagealloc
efi: provide empty efi_enter_virtual_mode implementation kasan, arm64: don't instrument functions that enable kasan
kasan: allow enabling stack tagging for tag-based mode
kasan: adjust kasan_stack_oob for tag-based mode

 arch/arm64/kernel/setup.c | 2 +-
 include/linux/efi.h       | 4 ++++
 init/main.c               | 2 +-
 kernel/fork.c             | 3 ++-
 lib/test_kasan.c          | 2 +-
 scripts/Makefile.kasan    | 3 ++-
 6 files changed, 11 insertions(+), 5 deletions(-)
Signature · 1 line
2.28.0.163.g6104cc2f0b6-goog
#1 lore raw

PATCH v2 1/5 kasan: don't tag stacks allocated with pagealloc

This patch prepares Software Tag-Based KASAN for stack tagging support.

With Tag-Based KASAN when kernel stacks are allocated via pagealloc (which happens when CONFIG_VMAP_STACK is not enabled), they get tagged. KASAN instrumentation doesn't expect the sp register to be tagged, and this leads to false-positive reports.

Fix by resetting the tag of kernel stack pointers after allocation.

---
 kernel/fork.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
kernel/fork.c +2 -1
index efc5493203ae..75415f5e647c 100644
@@ -261,7 +261,7 @@ static unsigned long *alloc_thread_stack_node(struct task_struct *tsk, int node)
 					     THREAD_SIZE_ORDER);
 
 	if (likely(page)) {
-		tsk->stack = page_address(page);
+		tsk->stack = kasan_reset_tag(page_address(page));
 		return tsk->stack;
 	}
 	return NULL;
@@ -307,6 +307,7 @@ static unsigned long *alloc_thread_stack_node(struct task_struct *tsk,
 {
 	unsigned long *stack;
 	stack = kmem_cache_alloc_node(thread_stack_cache, THREADINFO_GFP, node);
+	stack = kasan_reset_tag(stack);
 	tsk->stack = stack;
 	return stack;
 }
Signature · 1 line
2.28.0.163.g6104cc2f0b6-goog
#2 lore raw

PATCH v2 2/5 efi: provide empty efi_enter_virtual_mode implementation

In reply to Andrey Konovalov

When CONFIG_EFI is not enabled, we might get an undefined reference to efi_enter_virtual_mode() error, if this efi_enabled() call isn't inlined into start_kernel(). This happens in particular, if start_kernel() is annodated with __no_sanitize_address.

---
 include/linux/efi.h | 4 ++++
 1 file changed, 4 insertions(+)
include/linux/efi.h +4 -0
index 05c47f857383..73db1ae04cef 100644
@@ -606,7 +606,11 @@ extern void *efi_get_pal_addr (void);
 extern void efi_map_pal_code (void);
 extern void efi_memmap_walk (efi_freemem_callback_t callback, void *arg);
 extern void efi_gettimeofday (struct timespec64 *ts);
+#ifdef CONFIG_EFI
 extern void efi_enter_virtual_mode (void);	/* switch EFI to virtual mode, if possible */
+#else
+static inline void efi_enter_virtual_mode (void) {}
+#endif
 #ifdef CONFIG_X86
 extern efi_status_t efi_query_variable_store(u32 attributes,
 					     unsigned long size,
Signature · 1 line
2.28.0.163.g6104cc2f0b6-goog
maintainer Acked-by on v2 2/5
#3 lore raw

Re: [PATCH v2 2/5] efi: provide empty efi_enter_virtual_mode implementation

Quoted 8 lines · Andrey Konovalov

When CONFIG_EFI is not enabled, we might get an undefined reference to efi_enter_virtual_mode() error, if this efi_enabled() call isn't inlined into start_kernel(). This happens in particular, if start_kernel() is annodated with __no_sanitize_address.

Quoted 23 lines
---
 include/linux/efi.h | 4 ++++
 1 file changed, 4 insertions(+)
include/linux/efi.h +4 -1
index 05c47f857383..73db1ae04cef 100644
@@ -606,7 +606,11 @@ extern void *efi_get_pal_addr (void);
 extern void efi_map_pal_code (void);
 extern void efi_memmap_walk (efi_freemem_callback_t callback, void *arg);
 extern void efi_gettimeofday (struct timespec64 *ts);
+#ifdef CONFIG_EFI
 extern void efi_enter_virtual_mode (void);     /* switch EFI to virtual mode, if possible */
+#else
+static inline void efi_enter_virtual_mode (void) {}
+#endif
 #ifdef CONFIG_X86
 extern efi_status_t efi_query_variable_store(u32 attributes,
                                             unsigned long size,
--

2.28.0.163.g6104cc2f0b6-goog

#4 lore raw

PATCH v2 3/5 kasan, arm64: don't instrument functions that enable kasan

In reply to Andrey Konovalov

This patch prepares Software Tag-Based KASAN for stack tagging support.

With stack tagging enabled, KASAN tags stack variable in each function in its prologue. In start_kernel() stack variables get tagged before KASAN is enabled via setup_arch()->kasan_init(). As the result the tags for start_kernel()'s stack variables end up in the temporary shadow memory. Later when KASAN gets enabled, switched to normal shadow, and starts checking tags, this leads to false-positive reports, as proper tags are missing in normal shadow.

Disable KASAN instrumentation for start_kernel(). Also disable it for arm64's setup_arch() as a precaution (it doesn't have any stack variables right now).

---
 arch/arm64/kernel/setup.c | 2 +-
 init/main.c               | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
arch/arm64/kernel/setup.c +1 -1
index 93b3844cf442..575da075a2b9 100644
@@ -276,7 +276,7 @@ arch_initcall(reserve_memblock_reserved_regions);
 
 u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
 
-void __init setup_arch(char **cmdline_p)
+void __init __no_sanitize_address setup_arch(char **cmdline_p)
 {
 	init_mm.start_code = (unsigned long) _text;
 	init_mm.end_code   = (unsigned long) _etext;
init/main.c +1 -1
index 0ead83e86b5a..7e5e25d9fe42 100644
@@ -827,7 +827,7 @@ void __init __weak arch_call_rest_init(void)
 	rest_init();
 }
 
-asmlinkage __visible void __init start_kernel(void)
+asmlinkage __visible void __init __no_sanitize_address start_kernel(void)
 {
 	char *command_line;
 	char *after_dashes;
Signature · 1 line
2.28.0.163.g6104cc2f0b6-goog
maintainer Acked-by on v2 3/5
#5 lore raw

Re: [PATCH v2 3/5] kasan, arm64: don't instrument functions that enable kasan

Quoted 10 lines · Andrey Konovalov

This patch prepares Software Tag-Based KASAN for stack tagging support.

With stack tagging enabled, KASAN tags stack variable in each function in its prologue. In start_kernel() stack variables get tagged before KASAN is enabled via setup_arch()->kasan_init(). As the result the tags for start_kernel()'s stack variables end up in the temporary shadow memory. Later when KASAN gets enabled, switched to normal shadow, and starts checking tags, this leads to false-positive reports, as proper tags are missing in normal shadow.

Quoted 5 lines

Disable KASAN instrumentation for start_kernel(). Also disable it for arm64's setup_arch() as a precaution (it doesn't have any stack variables right now).

I thought I acked this already. Either way:

#6 lore raw

Re: [PATCH v2 3/5] kasan, arm64: don't instrument functions that enable kasan

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

This patch prepares Software Tag-Based KASAN for stack tagging support.

With stack tagging enabled, KASAN tags stack variable in each function in its prologue. In start_kernel() stack variables get tagged before KASAN is enabled via setup_arch()->kasan_init(). As the result the tags for start_kernel()'s stack variables end up in the temporary shadow memory. Later when KASAN gets enabled, switched to normal shadow, and starts checking tags, this leads to false-positive reports, as proper tags are missing in normal shadow.

Disable KASAN instrumentation for start_kernel(). Also disable it for arm64's setup_arch() as a precaution (it doesn't have any stack variables right now).

Quoted 5 lines
Quoted 1 line

I thought I acked this already. Either way:

Sorry, I forgot to include that into v2. Thanks!

#7 lore raw

PATCH v2 4/5 kasan: allow enabling stack tagging for tag-based mode

In reply to Andrey Konovalov

Use CONFIG_KASAN_STACK to enable stack tagging.

Note, that HWASAN short granules [1] are disabled. Supporting those will require more kernel changes.

[1] https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html

---
 scripts/Makefile.kasan | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
scripts/Makefile.kasan +2 -1
index 03757cc60e06..f4beee1b0013 100644
@@ -44,7 +44,8 @@ else
 endif
 
 CFLAGS_KASAN := -fsanitize=kernel-hwaddress \
-		-mllvm -hwasan-instrument-stack=0 \
+		-mllvm -hwasan-instrument-stack=$(CONFIG_KASAN_STACK) \
+		-mllvm -hwasan-use-short-granules=0 \
 		$(instrumentation_flags)
 
 endif # CONFIG_KASAN_SW_TAGS
Signature · 1 line
2.28.0.163.g6104cc2f0b6-goog
#8 lore raw

PATCH v2 5/5 kasan: adjust kasan_stack_oob for tag-based mode

In reply to Andrey Konovalov

Use OOB_TAG_OFF as access offset to land the access into the next granule.

---
 lib/test_kasan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
lib/test_kasan.c +1 -1
index 7674616d0c37..5d3f496893ef 100644
@@ -488,7 +488,7 @@ static noinline void __init kasan_global_oob(void)
 static noinline void __init kasan_stack_oob(void)
 {
 	char stack_array[10];
-	volatile int i = 0;
+	volatile int i = OOB_TAG_OFF;
 	char *p = &stack_array[ARRAY_SIZE(stack_array) + i];
 
 	pr_info("out-of-bounds on stack\n");
Signature · 1 line
2.28.0.163.g6104cc2f0b6-goog