From patchwork Tue Mar 1 20:01:05 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Rutland X-Patchwork-Id: 63346 Delivered-To: patch@linaro.org Received: by 10.112.199.169 with SMTP id jl9csp2020579lbc; Tue, 1 Mar 2016 12:03:06 -0800 (PST) X-Received: by 10.66.122.135 with SMTP id ls7mr32981539pab.59.1456862586755; Tue, 01 Mar 2016 12:03:06 -0800 (PST) Return-Path: Received: from bombadil.infradead.org (bombadil.infradead.org. [2001:1868:205::9]) by mx.google.com with ESMTPS id p63si14765783pfj.212.2016.03.01.12.03.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Mar 2016 12:03:06 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) client-ip=2001:1868:205::9; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) smtp.mailfrom=linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1aaqUT-000808-ES; Tue, 01 Mar 2016 20:01:53 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1aaqUP-0007oo-P7 for linux-arm-kernel@lists.infradead.org; Tue, 01 Mar 2016 20:01:50 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id AD24849; Tue, 1 Mar 2016 12:00:30 -0800 (PST) Received: from leverpostej.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 8F7313F25E; Tue, 1 Mar 2016 12:01:24 -0800 (PST) From: Mark Rutland To: linux-arm-kernel@lists.infradead.org Subject: [PATCHv2] arm64: kasan: clear stale stack poison Date: Tue, 1 Mar 2016 20:01:05 +0000 Message-Id: <1456862465-31505-1-git-send-email-mark.rutland@arm.com> X-Mailer: git-send-email 1.9.1 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160301_120149_851184_6B5BAE07 X-CRM114-Status: GOOD ( 14.58 ) X-Spam-Score: -6.9 (------) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-6.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [217.140.101.70 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Lorenzo Pieralisi , Ard Biesheuvel , Catalin Marinas , Will Deacon , Alexander Potapenko , Andrey Ryabinin MIME-Version: 1.0 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org When a CPU is shut down or placed into a low power state, the functions on the critical path to firmware never return, and hence their epilogues never execute. When using KASAN, this means that the shadow entries for the corresponding stack are poisoned but never unpoisoned. When a CPU subsequently re-enters the kernel via another path, and begins using the stack, it may hit stale poison values, leading to false-positive KASAN failures. We can't ensure that all functions on the critical path are not instrumented. For CPU hotplug this includes lots of core code starting from secondary_start_kernel, and for CPU idle we can't ensure that specific functions are not instrumented, as the compiler always poisons the stack even when told to not instrument a function: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69863 This patch works around the issue by forcefully unpoisoning the shadow region for all stack on the critical path, before we return to instrumented C code. As we cannot statically determine the stack usage of code in the critical path, we must clear the shadow for all remaining stack, meaning that we must clear up to 2K of shadow memory each time a CPU enters the kernel from idle or hotplug. Signed-off-by: Mark Rutland Cc: Alexander Potapenko Cc: Andrey Ryabinin Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: Lorenzo Pieralisi Cc: Will Deacon --- arch/arm64/include/asm/kasan.h | 40 ++++++++++++++++++++++++++++++++++------ arch/arm64/kernel/asm-offsets.c | 1 + arch/arm64/kernel/head.S | 2 ++ arch/arm64/kernel/sleep.S | 2 ++ 4 files changed, 39 insertions(+), 6 deletions(-) Since v1 [1]: * Remove unneeded offset * Simplify calculation For the timebeing I've retained the arm64-specific hotplug fix, though it might be possible to handle the hotplug case in common code (e.g. [2]). Mark. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/409466.html [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/412923.html -- 1.9.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel Reviewed-by: Catalin Marinas diff --git a/arch/arm64/include/asm/kasan.h b/arch/arm64/include/asm/kasan.h index 2774fa3..6f00b76 100644 --- a/arch/arm64/include/asm/kasan.h +++ b/arch/arm64/include/asm/kasan.h @@ -1,10 +1,30 @@ #ifndef __ASM_KASAN_H #define __ASM_KASAN_H -#ifndef __ASSEMBLY__ - +#ifndef LINKER_SCRIPT #ifdef CONFIG_KASAN +#ifdef __ASSEMBLY__ + +#include +#include + + /* + * Remove stale shadow posion for the stack left over from a prior + * hot-unplug or idle exit, from the lowest stack address in the + * thread_union up to the covering up to the current stack pointer. + * Shadow poison above this is preserved. + */ + .macro kasan_unpoison_stack + mov x1, sp + and x0, x1, #~(THREAD_SIZE - 1) + add x0, x0, #(THREAD_INFO_SIZE) + sub x1, x1, x0 + bl kasan_unpoison_shadow + .endm + +#else /* __ASSEMBLY__ */ + #include #include @@ -30,9 +50,17 @@ void kasan_init(void); asmlinkage void kasan_early_init(void); -#else +#endif /* __ASSEMBLY__ */ + +#else /* CONFIG_KASAN */ + +#ifdef __ASSEMBLY__ + .macro kasan_unpoison_stack + .endm +#else /* __ASSEMBLY */ static inline void kasan_init(void) { } -#endif +#endif /* __ASSEMBLY__ */ -#endif -#endif +#endif /* CONFIG_KASAN */ +#endif /* LINKER_SCRIPT */ +#endif /* __ASM_KASAN_H */ diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c index fffa4ac6..c615fa3 100644 --- a/arch/arm64/kernel/asm-offsets.c +++ b/arch/arm64/kernel/asm-offsets.c @@ -39,6 +39,7 @@ int main(void) DEFINE(TI_ADDR_LIMIT, offsetof(struct thread_info, addr_limit)); DEFINE(TI_TASK, offsetof(struct thread_info, task)); DEFINE(TI_CPU, offsetof(struct thread_info, cpu)); + DEFINE(THREAD_INFO_SIZE, sizeof(struct thread_info)); BLANK(); DEFINE(THREAD_CPU_CONTEXT, offsetof(struct task_struct, thread.cpu_context)); BLANK(); diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index 917d981..35ae2cb 100644 --- a/arch/arm64/kernel/head.S +++ b/arch/arm64/kernel/head.S @@ -29,6 +29,7 @@ #include #include #include +#include #include #include #include @@ -616,6 +617,7 @@ ENTRY(__secondary_switched) and x0, x0, #~(THREAD_SIZE - 1) msr sp_el0, x0 // save thread_info mov x29, #0 + kasan_unpoison_stack b secondary_start_kernel ENDPROC(__secondary_switched) diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S index e33fe33..3ad7681 100644 --- a/arch/arm64/kernel/sleep.S +++ b/arch/arm64/kernel/sleep.S @@ -2,6 +2,7 @@ #include #include #include +#include .text /* @@ -145,6 +146,7 @@ ENTRY(cpu_resume_mmu) ENDPROC(cpu_resume_mmu) .popsection cpu_resume_after_mmu: + kasan_unpoison_stack mov x0, #0 // return zero on success ldp x19, x20, [sp, #16] ldp x21, x22, [sp, #32]