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=-5.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 57EAFC352A3 for ; Thu, 13 Feb 2020 06:08:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D475221734 for ; Thu, 13 Feb 2020 06:08:31 +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="Bo8PZYyO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D475221734 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 1DF1A6B0518; Thu, 13 Feb 2020 01:08:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1908F6B0519; Thu, 13 Feb 2020 01:08:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0804F6B051A; Thu, 13 Feb 2020 01:08:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0122.hostedemail.com [216.40.44.122]) by kanga.kvack.org (Postfix) with ESMTP id E37AA6B0518 for ; Thu, 13 Feb 2020 01:08:30 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id B0E65181AC9CB for ; Thu, 13 Feb 2020 06:08:30 +0000 (UTC) X-FDA: 76484074380.29.alarm61_100971a73d55a X-HE-Tag: alarm61_100971a73d55a X-Filterd-Recvd-Size: 5840 Received: from pegase1.c-s.fr (pegase1.c-s.fr [93.17.236.30]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Thu, 13 Feb 2020 06:08:30 +0000 (UTC) Received: from localhost (mailhub1-int [192.168.12.234]) by localhost (Postfix) with ESMTP id 48J5fg1vBSz9txqP; Thu, 13 Feb 2020 07:08:27 +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=Bo8PZYyO; 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 W3ooT9PICKBs; Thu, 13 Feb 2020 07:08:27 +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 48J5fg0KvXz9txpx; Thu, 13 Feb 2020 07:08:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=c-s.fr; s=mail; t=1581574107; bh=AKmjbGNoqXYmXrUzT0AKVVfZXpSdbAFvNtOP0PQkAVk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Bo8PZYyOEZ7qD+MevGwQsu8UvvqAisxHMQmlLFbb5ZCOOdcEU4xLcfXvv0aEn1OwF 3fkTo5JOrKAuArtvzKFZe5s3giihd2TCJnKCFWYoV92r76w9omaLNFtSsL82MjHDrb voS3bNq/47yELGACslffHb3qsSDzMPtFyeJQjXQU= Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id D2FE68B752; Thu, 13 Feb 2020 07:08:27 +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 5eeoAwa3yMGD; Thu, 13 Feb 2020 07:08:27 +0100 (CET) Received: from [192.168.4.90] (unknown [192.168.4.90]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 2F9C88B795; Thu, 13 Feb 2020 07:08:27 +0100 (CET) Subject: Re: [PATCH v7 4/4] powerpc: Book3S 64-bit "heavyweight" KASAN support To: Daniel Axtens , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, kasan-dev@googlegroups.com, aneesh.kumar@linux.ibm.com, bsingharora@gmail.com Cc: Michael Ellerman References: <20200213004752.11019-1-dja@axtens.net> <20200213004752.11019-5-dja@axtens.net> From: Christophe Leroy Message-ID: <67370fc6-8fe8-c5ba-d97a-4a4c399b0ae0@c-s.fr> Date: Thu, 13 Feb 2020 07:08:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200213004752.11019-5-dja@axtens.net> 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 13/02/2020 =C3=A0 01:47, Daniel Axtens a =C3=A9crit=C2=A0: > KASAN support on Book3S is a bit tricky to get right: >=20 > - It would be good to support inline instrumentation so as to be able= to > catch stack issues that cannot be caught with outline mode. >=20 > - Inline instrumentation requires a fixed offset. >=20 > - Book3S runs code in real mode after booting. Most notably a lot of = KVM > runs in real mode, and it would be good to be able to instrument it= . >=20 > - Because code runs in real mode after boot, the offset has to point = to > valid memory both in and out of real mode. >=20 > [ppc64 mm note: The kernel installs a linear mapping at effective > address c000... onward. This is a one-to-one mapping with physical > memory from 0000... onward. Because of how memory accesses work on > powerpc 64-bit Book3S, a kernel pointer in the linear map accesses= the > same memory both with translations on (accessing as an 'effective > address'), and with translations off (accessing as a 'real > address'). This works in both guests and the hypervisor. For more > details, see s5.7 of Book III of version 3 of the ISA, in particul= ar > the Storage Control Overview, s5.7.3, and s5.7.5 - noting that thi= s > KASAN implementation currently only supports Radix.] >=20 > One approach is just to give up on inline instrumentation. This way all > checks can be delayed until after everything set is up correctly, and t= he > address-to-shadow calculations can be overridden. However, the features= and > speed boost provided by inline instrumentation are worth trying to do > better. >=20 > If _at compile time_ it is known how much contiguous physical memory a > system has, the top 1/8th of the first block of physical memory can be = set > aside for the shadow. This is a big hammer and comes with 3 big > consequences: >=20 > - there's no nice way to handle physically discontiguous memory, so o= nly > the first physical memory block can be used. >=20 > - kernels will simply fail to boot on machines with less memory than > specified when compiling. >=20 > - kernels running on machines with more memory than specified when > compiling will simply ignore the extra memory. >=20 > Implement and document KASAN this way. The current implementation is Ra= dix > only. >=20 > Despite the limitations, it can still find bugs, > e.g. http://patchwork.ozlabs.org/patch/1103775/ >=20 > At the moment, this physical memory limit must be set _even for outline > mode_. This may be changed in a later series - a different implementati= on > could be added for outline mode that dynamically allocates shadow at a > fixed offset. For example, see https://patchwork.ozlabs.org/patch/79521= 1/ >=20 > Suggested-by: Michael Ellerman > Cc: Balbir Singh # ppc64 out-of-line radix vers= ion > Cc: Christophe Leroy # ppc32 version > Signed-off-by: Daniel Axtens Reviewed-by: # focussed mainly on=20 Documentation and things impacting PPC32