From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753005AbbJMOPk (ORCPT ); Tue, 13 Oct 2015 10:15:40 -0400 Received: from mx2.parallels.com ([199.115.105.18]:57155 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751904AbbJMOPj (ORCPT ); Tue, 13 Oct 2015 10:15:39 -0400 Subject: Re: [PATCH v2 2/2] x86/process: Silence KASAN warnings in get_wchan() To: Dmitry Vyukov , Ingo Molnar References: <1444739750-29241-1-git-send-email-aryabinin@virtuozzo.com> <1444739750-29241-3-git-send-email-aryabinin@virtuozzo.com> <20151013134859.GB8843@gmail.com> CC: LKML , Thomas Gleixner , "H. Peter Anvin" , "x86@kernel.org" , Andrew Morton , Andy Lutomirski , Andrey Konovalov , Kostya Serebryany , Alexander Potapenko , kasan-dev , Borislav Petkov , Denys Vlasenko , Andi Kleen , Sasha Levin , Wolfram Gloger From: Andrey Ryabinin Message-ID: <561D1207.90501@virtuozzo.com> Date: Tue, 13 Oct 2015 17:15:35 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: US-EXCH2.sw.swsoft.com (10.255.249.46) To US-EXCH.sw.swsoft.com (10.255.249.47) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/13/2015 04:57 PM, Dmitry Vyukov wrote: > On Tue, Oct 13, 2015 at 3:48 PM, Ingo Molnar wrote: >> >> * Andrey Ryabinin wrote: >> >>> get_wchan() is racy by design, it may access volatile stack >>> of running task, thus it may access redzone in a stack frame >>> and cause KASAN to warn about this. >>> >>> Use READ_ONCE_NOCHECK() to silence these warnings. >>> >>> Reported-by: Sasha Levin >>> Signed-off-by: Andrey Ryabinin >>> --- >>> arch/x86/kernel/process.c | 6 +++--- >>> 1 file changed, 3 insertions(+), 3 deletions(-) >>> >>> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c >>> index 39e585a..e28db18 100644 >>> --- a/arch/x86/kernel/process.c >>> +++ b/arch/x86/kernel/process.c >>> @@ -550,14 +550,14 @@ unsigned long get_wchan(struct task_struct *p) >>> if (sp < bottom || sp > top) >>> return 0; >>> >>> - fp = READ_ONCE(*(unsigned long *)sp); >>> + fp = READ_ONCE_NOCHECK(*(unsigned long *)sp); >>> do { >>> if (fp < bottom || fp > top) >>> return 0; >>> - ip = READ_ONCE(*(unsigned long *)(fp + sizeof(unsigned long))); >>> + ip = READ_ONCE_NOCHECK(*(unsigned long *)(fp + sizeof(unsigned long))); >>> if (!in_sched_functions(ip)) >>> return ip; >>> - fp = READ_ONCE(*(unsigned long *)fp); >>> + fp = READ_ONCE_NOCHECK(*(unsigned long *)fp); >>> } while (count++ < 16 && p->state != TASK_RUNNING); >>> return 0; >>> } >> >> Hm, exactly how is the 'red zone' defined? Is this about the current task mostly, >> or when doing get_wchan() on other tasks? > > > When code is compiled with AddressSanitizer, most variables on stack > have redzones around them, on entry function "poisons" these redzones > (any accesses to them will be flagged), on exit function "unpoisons" > these redzones. > An example bellow (stolen from slides - http://events.linuxfoundation.org/sites/events/files/slides/LinuxCon%20North%20America%202015%20KernelAddressSanitizer.pdf) The following function: void foo(void) { char a[328]; ... a[i] = 0; } will be transform by GCC to something like this: void foo(void) { char redzone1[32]; char a[328]; char redzone2[24]; char redzone3[32]; int *shadow = (&redzone1 >> 3) + shadow_offset; shadow[0] = 0xf1f1f1f1; // poison redzone1 shadow[11] = 0xf4f4f400; // poison redzone2 shadow[12] = 0xf3f3f3f3; // poison redzone3 ... __asan_store1(&a[i]); //check access to a[i] a[i] = 0; shadow[0] = shadow[11] = shadow[12] = 0; //unpoison redzones. }