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.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,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 55931C433E0 for ; Mon, 22 Mar 2021 14:33:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BFAFC6186A for ; Mon, 22 Mar 2021 14:33:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BFAFC6186A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=csgroup.eu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 654866B00CC; Mon, 22 Mar 2021 10:14:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 629816B00D4; Mon, 22 Mar 2021 10:14:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4CD646B00D5; Mon, 22 Mar 2021 10:14:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0025.hostedemail.com [216.40.44.25]) by kanga.kvack.org (Postfix) with ESMTP id 294FA6B00CC for ; Mon, 22 Mar 2021 10:14:17 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 8E9E48249980 for ; Mon, 22 Mar 2021 14:33:07 +0000 (UTC) X-FDA: 77947752414.04.8A588A3 Received: from pegase1.c-s.fr (pegase1.c-s.fr [93.17.236.30]) by imf21.hostedemail.com (Postfix) with ESMTP id 38FC3E016140 for ; Mon, 22 Mar 2021 14:33:04 +0000 (UTC) Received: from localhost (mailhub1-int [192.168.12.234]) by localhost (Postfix) with ESMTP id 4F3xmf1Jcpz9tyhT; Mon, 22 Mar 2021 15:32:50 +0100 (CET) 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 Ddg49OyYyGfy; Mon, 22 Mar 2021 15:32:50 +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 4F3xmd5qZNz9tyhR; Mon, 22 Mar 2021 15:32:49 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 1785C8B79F; Mon, 22 Mar 2021 15:32:55 +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 6Tx7BT7WTY9N; Mon, 22 Mar 2021 15:32:54 +0100 (CET) Received: from [192.168.4.90] (unknown [192.168.4.90]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 3E4318B79C; Mon, 22 Mar 2021 15:32:54 +0100 (CET) Subject: Re: [PATCH v11 0/6] KASAN for powerpc64 radix 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 References: <20210319144058.772525-1-dja@axtens.net> From: Christophe Leroy Message-ID: <5a3b5952-b31f-42bf-eaf4-ea24444f8df6@csgroup.eu> Date: Mon, 22 Mar 2021 15:32:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210319144058.772525-1-dja@axtens.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 38FC3E016140 X-Stat-Signature: jusgweeii3mq8ze96i84a1qrarbfdsms Received-SPF: none (csgroup.eu>: No applicable sender policy available) receiver=imf21; identity=mailfrom; envelope-from=""; helo=pegase1.c-s.fr; client-ip=93.17.236.30 X-HE-DKIM-Result: none/none X-HE-Tag: 1616423584-536376 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 19/03/2021 =C3=A0 15:40, Daniel Axtens a =C3=A9crit=C2=A0: > Building on the work of Christophe, Aneesh and Balbir, I've ported > KASAN to 64-bit Book3S kernels running on the Radix MMU. >=20 > v11 applies to next-20210317. I had hoped to have it apply to > powerpc/next but once again there are changes in the kasan core that > clash. Also, thanks to mpe for fixing a build break with KASAN off. >=20 > I'm not sure how best to progress this towards actually being merged > when it has impacts across subsystems. I'd appreciate any input. Maybe > the first four patches could go in via the kasan tree, that should > make things easier for powerpc in a future cycle? >=20 > v10 rebases on top of next-20210125, fixing things up to work on top > of the latest changes, and fixing some review comments from > Christophe. I have tested host and guest with 64k pages for this spin. >=20 > There is now only 1 failing KUnit test: kasan_global_oob - gcc puts > the ASAN init code in a section called '.init_array'. Powerpc64 module > loading code goes through and _renames_ any section beginning with > '.init' to begin with '_init' in order to avoid some complexities > around our 24-bit indirect jumps. This means it renames '.init_array' > to '_init_array', and the generic module loading code then fails to > recognise the section as a constructor and thus doesn't run it. This > hack dates back to 2003 and so I'm not going to try to unpick it in > this series. (I suspect this may have previously worked if the code > ended up in .ctors rather than .init_array but I don't keep my old > binaries around so I have no real way of checking.) >=20 > (The previously failing stack tests are now skipped due to more > accurate configuration settings.) >=20 > Details from v9: This is a significant reworking of the previous > versions. Instead of the previous approach which supported inline > instrumentation, this series provides only outline instrumentation. >=20 > To get around the problem of accessing the shadow region inside code we= run > with translations off (in 'real mode'), we we restrict checking to when > translations are enabled. This is done via a new hook in the kasan core= and > by excluding larger quantites of arch code from instrumentation. The up= side > is that we no longer require that you be able to specify the amount of > physically contiguous memory on the system at compile time. Hopefully t= his > is a better trade-off. More details in patch 6. >=20 > kexec works. Both 64k and 4k pages work. Running as a KVM host works, b= ut > nothing in arch/powerpc/kvm is instrumented. It's also potentially a bi= t > fragile - if any real mode code paths call out to instrumented code, th= ings > will go boom. >=20 In the discussion we had long time ago,=20 https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20190806233827.16= 454-5-dja@axtens.net/#2321067=20 , I challenged you on why it was not possible to implement things the sam= e way as other=20 architectures, in extenso with an early mapping. Your first answer was that too many things were done in real mode at star= tup. After some discussion=20 you said that finally there was not that much things at startup but the i= ssue was KVM. Now you say that instrumentation on KVM is fully disabled. So my question is, if KVM is not a problem anymore, why not go the standa= rd way with an early shadow=20 ? Then you could also support inline instrumentation. Christophe