Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758212AbcCCRp7 (ORCPT ); Thu, 3 Mar 2016 12:45:59 -0500 Received: from mail-wm0-f45.google.com ([74.125.82.45]:37027 "EHLO mail-wm0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756602AbcCCRp5 convert rfc822-to-8bit (ORCPT ); Thu, 3 Mar 2016 12:45:57 -0500 MIME-Version: 1.0 In-Reply-To: <20160303174015.GG19139@leverpostej> References: <1457024068-2236-1-git-send-email-mark.rutland@arm.com> <20160303174015.GG19139@leverpostej> Date: Thu, 3 Mar 2016 18:45:55 +0100 Message-ID: Subject: Re: [PATCHv2 0/3] KASAN: clean stale poison upon cold re-entry to kernel From: Alexander Potapenko To: Mark Rutland Cc: Linux Memory Management List , mingo@redhat.com, Andrew Morton , Andrey Ryabinin , catalin.marinas@arm.com, lorenzo.pieralisi@arm.com, peterz@infradead.org, will.deacon@arm.com, LKML , linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3241 Lines: 70 On Thu, Mar 3, 2016 at 6:40 PM, Mark Rutland wrote: > Hi, > > On Thu, Mar 03, 2016 at 06:17:31PM +0100, Alexander Potapenko wrote: >> Please replace "ASAN" with "KASAN". >> >> On Thu, Mar 3, 2016 at 5:54 PM, Mark Rutland wrote: >> > Functions which the compiler has instrumented for ASAN place poison on >> > the stack shadow upon entry and remove this poison prior to returning. >> > >> > In some cases (e.g. hotplug and idle), CPUs may exit the kernel a number >> > of levels deep in C code. If there are any instrumented functions on >> > this critical path, these will leave portions of the idle thread stack >> > shadow poisoned. >> > >> > If a CPU returns to the kernel via a different path (e.g. a cold entry), >> > then depending on stack frame layout subsequent calls to instrumented >> > functions may use regions of the stack with stale poison, resulting in >> > (spurious) KASAN splats to the console. >> > >> > Contemporary GCCs always add stack shadow poisoning when ASAN is >> > enabled, even when asked to not instrument a function [1], so we can't >> > simply annotate functions on the critical path to avoid poisoning. >> > >> > Instead, this series explicitly removes any stale poison before it can >> > be hit. In the common hotplug case we clear the entire stack shadow in >> > common code, before a CPU is brought online. >> > >> > On architectures which perform a cold return as part of cpu idle may >> > retain an architecture-specific amount of stack contents. To retain the >> > poison for this retained context, the arch code must call the core KASAN >> > code, passing a "watermark" stack pointer value beyond which shadow will >> > be cleared. Architectures which don't perform a cold return as part of >> > idle do not need any additional code. > > For the above, and the rest of the series, ASAN consistently refers to > the compiler AddressSanitizer feature, and KASAN consistently refers to > the Linux-specific infrastructure. A simple s/[^K]ASAN/KASAN/ would > arguably be wrong (e.g. when referring to GCC behaviour above). I don't think there's been any convention about the compiler feature name, we usually talked about ASan as a userspace tool and KASAN as a kernel-space one, although they share the compiler part. > If there is a this needs rework, then I'm happy to s/[^K]ASAN/ASan/ to > follow the usual ASan naming convention and avoid confusion. Otherwise, > spinning a v3 is simply churn. I don't insist on changing this, I should've chimed in before. Feel free to retain the above patch description. > Thanks, > Mark. -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind, leiten Sie diese bitte nicht weiter, informieren Sie den Absender und löschen Sie die E-Mail und alle Anhänge. Vielen Dank. This e-mail is confidential. If you are not the right addressee please do not forward it, please inform the sender, and please erase this e-mail including any attachments. Thanks.