From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753588AbdK1PYM (ORCPT ); Tue, 28 Nov 2017 10:24:12 -0500 Received: from foss.arm.com ([217.140.101.70]:55296 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751770AbdK1PYK (ORCPT ); Tue, 28 Nov 2017 10:24:10 -0500 Date: Tue, 28 Nov 2017 15:24:06 +0000 From: Mark Rutland To: Dmitry Vyukov Cc: Andrey Ryabinin , kasan-dev , Alexander Potapenko , LKML , linux-arm-kernel@lists.infradead.org, Dennis Zhou , Fengguang Wu Subject: Re: kasan: false use-after-scope warnings with KCOV Message-ID: <20171128152405.vkwxdbkbuokjt2hv@lakrids.cambridge.arm.com> References: <20171128123555.mo4ikj2ru6mkibwo@lakrids.cambridge.arm.com> <20171128141355.3pwgzfhji32lehf2@lakrids.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171128141355.3pwgzfhji32lehf2@lakrids.cambridge.arm.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 28, 2017 at 02:13:55PM +0000, Mark Rutland wrote: > On Tue, Nov 28, 2017 at 01:57:49PM +0100, Dmitry Vyukov wrote: > > On Tue, Nov 28, 2017 at 1:35 PM, Mark Rutland wrote: > > > As a heads-up, I'm seeing a number of what appear to be false-positive > > > use-after-scope warnings when I enable both KCOV and KASAN (inline or outline), > > > when using the Linaro 17.08 GCC7.1.1 for arm64. So far I haven't spotted these > > > without KCOV selected, and I'm only seeing these for sanitize-use-after-scope. > > > > > > The reports vary depending on configuration even with the same trigger. I'm not > > > sure if it's the reporting that's misleading, or whether the detection is going > > > wrong. > ... it looks suspiciously like something is setting up non-zero shadow > bytes, but not zeroing them upon return. It looks like this is the case. The hack below detects leftover poison on an exception return *before* the false-positive warning (example splat at the end of the email). With scripts/Makefile.kasan hacked to not pass -fsanitize-address-use-after-scope, I see no leftover poison. Unfortunately, there's not enough information left to say where exactly that happened. Given the report that Andrey linked to [1], it looks like the compiler is doing something wrong, and failing to clear some poison in some cases. Dennis noted [2] that this appears to be the case where inline functions are called in a loop. It sounds like this is a general GCC 7.x problem, on both x86_64 and arm64. As we don't have a smoking gun, it's still possible that something else is corrupting the shadow, but it seems unlikely. [1] https://lkml.kernel.org/r/20171128124534.3jvuala525wvn64r@wfg-t540p.sh.intel.com [2] https://lkml.kernel.org/r/20171127210301.GA55812@localhost.corp.microsoft.com Thanks, Mark. Hack -------- diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S index 6d14b8f29b5f..8191e122d6f4 100644 --- a/arch/arm64/kernel/entry.S +++ b/arch/arm64/kernel/entry.S @@ -220,6 +220,8 @@ alternative_else_nop_endif .endm .macro kernel_exit, el + mov x0, sp + bl kasan_assert_task_stack_is_clean_below .if \el != 0 disable_daif diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c index 405bba487df5..dab8a51ee52f 100644 --- a/mm/kasan/kasan.c +++ b/mm/kasan/kasan.c @@ -37,6 +37,8 @@ #include #include +#include + #include "kasan.h" #include "../slab.h" @@ -241,6 +243,33 @@ static __always_inline bool memory_is_poisoned(unsigned long addr, size_t size) return memory_is_poisoned_n(addr, size); } +/* + * In some contexts (e.g. when returning from an exception), all shadow beyond + * a certain point on the stack should be clear. This helper can be called by + * assembly code to verify this is the case. + */ +asmlinkage void kasan_assert_task_stack_is_clean_below(unsigned long watermark) +{ + unsigned long base; + + /* + * This is an arm64-specific hack. This should be fixed properly to + * discover and check the bounds of the current stack in an + * arch-agnostic manner. + */ + if (!on_task_stack(current, watermark)) + return; + + /* + * Calculate the task stack base address. Avoid using 'current' + * because this function is called by early resume code which hasn't + * yet set up the percpu register (%gs). + */ + base = watermark & ~(THREAD_SIZE - 1); + + WARN_ON_ONCE(memory_is_poisoned(base, watermark - base)); +} + static __always_inline void check_memory_region_inline(unsigned long addr, size_t size, bool write, unsigned long ret_ip) -------- Splat -------- [ 186.951300] WARNING: CPU: 1 PID: 2429 at mm/kasan/kasan.c:270 kasan_assert_task_stack_is_clean_below+0x144/0x150 [ 186.961418] Modules linked in: [ 186.964468] CPU: 1 PID: 2429 Comm: perf Not tainted 4.15.0-rc1-00001-g7780802c256e #6 [ 186.972249] Hardware name: ARM Juno development board (r1) (DT) [ 186.978133] task: ffff800933fe6900 task.stack: ffff80092c990000 [ 186.984019] pstate: 200003c5 (nzCv DAIF -PAN -UAO) [ 186.988789] pc : kasan_assert_task_stack_is_clean_below+0x144/0x150 [ 186.995022] lr : ret_fast_syscall+0x34/0x98 [ 186.999177] sp : ffff80092c997ec0 [ 187.002472] x29: ffff80092c997ff0 x28: ffff800933fe6900 [ 187.007760] x27: ffff200009264000 x26: 00000000000000f1 [ 187.013047] x25: 0000000000000124 x24: 0000000000000015 [ 187.018334] x23: 0000000060000000 x22: 0000ffffae4b7554 [ 187.023621] x21: 00000000ffffffff x20: 000060092de30000 [ 187.028908] x19: 0000000000000000 x18: 0000ffffd2ec5330 [ 187.034195] x17: 0000ffffae4b7530 x16: ffff200008270508 [ 187.039482] x15: 0000ffffae538588 x14: 0000000000000000 [ 187.044769] x13: ffffffffffffffff x12: ffffffffffffffff [ 187.050060] x11: 1ffff00125932f33 x10: ffff100125932f33 [ 187.055349] x9 : dfff200000000000 x8 : dfff200000000008 [ 187.060638] x7 : 1ffff00125932fd7 x6 : ffff100125932fd7 [ 187.065927] x5 : ffff80092c997ebf x4 : ffff100125932fd8 [ 187.071217] x3 : dfff200000000000 x2 : ffff100125932e30 [ 187.076506] x1 : ffff100125932e28 x0 : 00000000000000f8 [ 187.081793] Call trace: [ 187.084238] kasan_assert_task_stack_is_clean_below+0x144/0x150 [ 187.090122] ---[ end trace 9c3a99d1de859687 ]--- [ 187.212571] ================================================================== [ 187.219786] BUG: KASAN: use-after-scope in __save_stack_trace+0x1c8/0x2f0 [ 187.226537] Read of size 4 at addr ffff800930e4f048 by task true/2432 [ 187.232935] [ 187.234430] CPU: 2 PID: 2432 Comm: true Tainted: G W 4.15.0-rc1-00001-g7780802c256e #6 [ 187.243507] Hardware name: ARM Juno development board (r1) (DT) [ 187.249389] Call trace: [ 187.251830] dump_backtrace+0x0/0x320 [ 187.255477] show_stack+0x20/0x30 [ 187.258782] dump_stack+0x108/0x174 [ 187.262256] print_address_description+0x60/0x270 [ 187.266936] kasan_report+0x210/0x2f0 [ 187.270584] __asan_load4+0x84/0xa8 [ 187.274059] __save_stack_trace+0x1c8/0x2f0 [ 187.278224] save_stack_trace+0x24/0x30 [ 187.282044] kasan_kmalloc+0xd0/0x180 [ 187.285688] kasan_slab_alloc+0x14/0x20 [ 187.289508] kmem_cache_alloc+0x128/0x1e8 [ 187.293499] perf_event_mmap+0x2dc/0x968 [ 187.297405] mmap_region+0x24c/0xa60 [ 187.300963] do_mmap+0x404/0x640 [ 187.304178] vm_mmap_pgoff+0x15c/0x190 [ 187.307909] vm_mmap+0x70/0xb0 [ 187.310951] elf_map+0x114/0x150 [ 187.314165] load_elf_binary+0x728/0x1b84 [ 187.318158] search_binary_handler+0xe4/0x3b8 [ 187.322495] do_execveat_common.isra.12+0xaa4/0xc60 [ 187.327349] SyS_execve+0x48/0x60 [ 187.330650] el0_svc_naked+0x20/0x24 [ 187.334202] [ 187.335685] The buggy address belongs to the page: [ 187.340453] page:ffff7e0024c393c0 count:0 mapcount:0 mapping: (null) index:0x0 [ 187.348414] flags: 0x1fffc00000000000() [ 187.352240] raw: 1fffc00000000000 0000000000000000 0000000000000000 00000000ffffffff [ 187.359947] raw: 0000000000000000 ffff7e0024c393e0 0000000000000000 0000000000000000 [ 187.367643] page dumped because: kasan: bad access detected [ 187.373178] [ 187.374661] Memory state around the buggy address: [ 187.379428] ffff800930e4ef00: f1 f1 f8 f2 f2 f2 f2 f2 f2 f2 00 00 f2 f2 f2 f2 [ 187.386612] ffff800930e4ef80: f2 f2 00 00 f2 f2 f3 f3 f3 f3 f8 f8 f8 f8 f8 f8 [ 187.393795] >ffff800930e4f000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 00 00 00 00 00 00 [ 187.400973] ^ [ 187.406516] ffff800930e4f080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 187.413699] ffff800930e4f100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 187.420877] ================================================================== --------