From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D916AC2D0C8 for ; Thu, 12 Dec 2019 09:38:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7716422527 for ; Thu, 12 Dec 2019 09:38:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=c-s.fr header.i=@c-s.fr header.b="ud0LAurH" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7716422527 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=c-s.fr Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 114906B36CC; Thu, 12 Dec 2019 04:38:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0C5A16B36CD; Thu, 12 Dec 2019 04:38:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF7366B36CE; Thu, 12 Dec 2019 04:38:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0084.hostedemail.com [216.40.44.84]) by kanga.kvack.org (Postfix) with ESMTP id D68646B36CC for ; Thu, 12 Dec 2019 04:38:49 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id ADBBE180AD822 for ; Thu, 12 Dec 2019 09:38:49 +0000 (UTC) X-FDA: 76255989978.29.boot82_4cfd9e512e84a X-HE-Tag: boot82_4cfd9e512e84a X-Filterd-Recvd-Size: 6416 Received: from pegase1.c-s.fr (pegase1.c-s.fr [93.17.236.30]) by imf50.hostedemail.com (Postfix) with ESMTP for ; Thu, 12 Dec 2019 09:38:48 +0000 (UTC) Received: from localhost (mailhub1-ext [192.168.12.233]) by localhost (Postfix) with ESMTP id 47YTJQ19QQz9tx9d; Thu, 12 Dec 2019 10:38:46 +0100 (CET) Authentication-Results: localhost; dkim=pass reason="1024-bit key; insecure key" header.d=c-s.fr header.i=@c-s.fr header.b=ud0LAurH; dkim-adsp=pass; dkim-atps=neutral X-Virus-Scanned: Debian amavisd-new at c-s.fr Received: from pegase1.c-s.fr ([192.168.12.234]) by localhost (pegase1.c-s.fr [192.168.12.234]) (amavisd-new, port 10024) with ESMTP id PtgGjD3L2HhS; Thu, 12 Dec 2019 10:38:46 +0100 (CET) Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192]) by pegase1.c-s.fr (Postfix) with ESMTP id 47YTJQ04Spz9tx9b; Thu, 12 Dec 2019 10:38:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=c-s.fr; s=mail; t=1576143526; bh=PmEFgaQ7Eo9rbAL5MPouRGU/8Glf/6NoE8/kyEXX9XI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ud0LAurHVCHTtzHonbn8ggiFwj8yqRLCq120So6BnJYTKnINs+gq8gijKGFlcEk8d +TgnRymV/wNbxtAsJKay2iOmRUp+H61LLodMFeYPw1Athio8oP8JCZjOortSPz5NQK 1pwHjkeNU9ObsJxl02zEkD5UarY4Tr0gAvrMwPFM= Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 1E80E8B85B; Thu, 12 Dec 2019 10:38:47 +0100 (CET) X-Virus-Scanned: amavisd-new at c-s.fr Received: from messagerie.si.c-s.fr ([127.0.0.1]) by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id kkSWjlcM3lXj; Thu, 12 Dec 2019 10:38:47 +0100 (CET) Received: from [192.168.4.90] (unknown [192.168.4.90]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 350948B776; Thu, 12 Dec 2019 10:38:46 +0100 (CET) Subject: Re: [PATCH v2 4/4] powerpc: Book3S 64-bit "heavyweight" KASAN support To: Balbir Singh , Daniel Axtens , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-xtensa@linux-xtensa.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kasan-dev@googlegroups.com, aneesh.kumar@linux.ibm.com, Dmitry Vyukov , Andrey Ryabinin References: <20191210044714.27265-1-dja@axtens.net> <20191210044714.27265-5-dja@axtens.net> <71751e27-e9c5-f685-7a13-ca2e007214bc@gmail.com> <875zincu8a.fsf@dja-thinkpad.axtens.net> <2e0f21e6-7552-815b-1bf3-b54b0fc5caa9@gmail.com> <87wob3aqis.fsf@dja-thinkpad.axtens.net> <1bffad2d-db13-9808-afc9-5594f02dcf01@gmail.com> From: Christophe Leroy Message-ID: <2f017b74-b6f4-5723-591a-fe7525b85419@c-s.fr> Date: Thu, 12 Dec 2019 10:38:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <1bffad2d-db13-9808-afc9-5594f02dcf01@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Le 12/12/2019 =C3=A0 08:42, Balbir Singh a =C3=A9crit=C2=A0: >=20 >=20 > On 12/12/19 1:24 am, Daniel Axtens wrote: >> Hi Balbir, >> >>>>>> +Discontiguous memory can occur when you have a machine with memor= y spread >>>>>> +across multiple nodes. For example, on a Talos II with 64GB of RA= M: >>>>>> + >>>>>> + - 32GB runs from 0x0 to 0x0000_0008_0000_0000, >>>>>> + - then there's a gap, >>>>>> + - then the final 32GB runs from 0x0000_2000_0000_0000 to 0x0000_= 2008_0000_0000 >>>>>> + >>>>>> +This can create _significant_ issues: >>>>>> + >>>>>> + - If we try to treat the machine as having 64GB of _contiguous_ = RAM, we would >>>>>> + assume that ran from 0x0 to 0x0000_0010_0000_0000. We'd then r= eserve the >>>>>> + last 1/8th - 0x0000_000e_0000_0000 to 0x0000_0010_0000_0000 as= the shadow >>>>>> + region. But when we try to access any of that, we'll try to ac= cess pages >>>>>> + that are not physically present. >>>>>> + >>>>> >>>>> If we reserved memory for KASAN from each node (discontig region), = we might survive >>>>> this no? May be we need NUMA aware KASAN? That might be a generic c= hange, just thinking >>>>> out loud. >>>> >>>> The challenge is that - AIUI - in inline instrumentation, the compil= er >>>> doesn't generate calls to things like __asan_loadN and >>>> __asan_storeN. Instead it uses -fasan-shadow-offset to compute the >>>> checks, and only calls the __asan_report* family of functions if it >>>> detects an issue. This also matches what I can observe with objdump >>>> across outline and inline instrumentation settings. >>>> >>>> This means that for this sort of thing to work we would need to eith= er >>>> drop back to out-of-line calls, or teach the compiler how to use a >>>> nonlinear, NUMA aware mem-to-shadow mapping. >>> >>> Yes, out of line is expensive, but seems to work well for all use cas= es. >> >> I'm not sure this is true. Looking at scripts/Makefile.kasan, allocas, >> stacks and globals will only be instrumented if you can provide >> KASAN_SHADOW_OFFSET. In the case you're proposing, we can't provide a >> static offset. I _think_ this is a compiler limitation, where some of >> those instrumentations only work/make sense with a static offset, but >> perhaps that's not right? Dmitry and Andrey, can you shed some light o= n >> this? >> >=20 > From what I can read, everything should still be supported, the info p= age > for gcc states that globals, stack asan should be enabled by default. > allocas may have limited meaning if stack-protector is turned on (no?) Where do you read that ? As far as I can see, there is not much details about=20 -fsanitize=3Dkernel-address and -fasan-shadow-offset=3Dnumber in GCC doc=20 (https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html) [...] >> >=20 > I think I got CONFIG_PHYS_MEM_SIZE_FOR_KASN wrong, honestly I don't get= why > we need this size? The size is in MB and the default is 0. >=20 > Why does the powerpc port of KASAN need the SIZE to be explicitly speci= fied? >=20 AFAICS, it is explained in details in Daniel's commit log. That's=20 because on book3s64, KVM requires KASAN to also work when MMU is off. The 0 default is for when CONFIG_KASAN is not selected, in order to=20 avoid a forest of #ifdefs in the code. Christophe