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=-12.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 72380C433DB for ; Fri, 5 Feb 2021 18:11:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0555A64E50 for ; Fri, 5 Feb 2021 18:11:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0555A64E50 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 33D546B0070; Fri, 5 Feb 2021 13:11:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2ED286B0071; Fri, 5 Feb 2021 13:11:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1DD846B0073; Fri, 5 Feb 2021 13:11:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0003.hostedemail.com [216.40.44.3]) by kanga.kvack.org (Postfix) with ESMTP id 086016B0070 for ; Fri, 5 Feb 2021 13:11:10 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id C05AF3629 for ; Fri, 5 Feb 2021 18:11:09 +0000 (UTC) X-FDA: 77785005858.13.43E1DDF Received: from mail-vk1-f181.google.com (mail-vk1-f181.google.com [209.85.221.181]) by imf02.hostedemail.com (Postfix) with ESMTP id AA94E40001FF for ; Fri, 5 Feb 2021 18:11:07 +0000 (UTC) Received: by mail-vk1-f181.google.com with SMTP id a6so1668051vkb.8 for ; Fri, 05 Feb 2021 10:11:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=F4x29TTVEpw+IQOs4pBG2aQj/4xmoAAS+aT8UOnwOmY=; b=qknmJZd3jqr6x5X39DF2bWa4iCWwABpUdPV+kiRS7BjkpstQ3R85pT/tbr5d3hNpB9 yW0LXkiBIQ9AFs9DG2uvmihC17ZgotzN27Hng1dlGt5QTun/RUerKK2911tPvuoXn1ZI 4Qj5x0Fa4n/4T20Qe+2kDzkJuUwxbIOcCOEdtKU2SULF01iC1zgPMTeESFhTMb2BjGOz xfKAZYqWDlQvvnzppXYrhii9X4yNttSXp2f+ubulxYF5MhWK7sPq9jj178SvqlBEpC5U 9Frwc1oFfSbQaJhEktTE7yUVcL/0L7g33b9cogvvwjWiH0rNtSaE0XoSdkY1RCp4AF4l MwXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=F4x29TTVEpw+IQOs4pBG2aQj/4xmoAAS+aT8UOnwOmY=; b=uDQ8S9PscfHgHfO57p/kkdE2DJK2QcxkfvMR5nseEoMEmcWQgKAVwSQEkm9+/wbStp +GFZFMTozWKWfKTJuYH/KxTz/ndub/5yPi/lTyQRyRRp/nZqRz4Wy7kVSH6ib/W+44zX C9k8nIr7h8igG7F8aqJ10WdrJe0471u/lkh0pwmcdR+JtyLjsnQXgysKjmZFOE7szKti PH2nMFMI7HaGftfF8hCYbZwDdVSJajeXaWkkLXTCni0SoOF/rL6SDrwHhuNugvayz0Jn unJMGnzHT7YNlbWvNGGd42DLZg+ZXRKqpruA+84SvOtM0fQX0fj904j8iL0+VtoNAEGm IPQg== X-Gm-Message-State: AOAM532+PoDScuwOQVgAudrshX32VnOrDMmSJjqJIFytemTiSspjuD0g QBnS9N50tTQZ/JHRTV/w2BzusHpxXq258TOsDls= X-Google-Smtp-Source: ABdhPJyQSyKITQ1MekomM876tjivL1ZvoCSAVcqpJpbeCFMyFC9uD/Ttet6N6ReP2+QW6Yc6xVzXQLrj29pjrTCK+Po= X-Received: by 2002:a1f:9c57:: with SMTP id f84mr4084825vke.2.1612548668509; Fri, 05 Feb 2021 10:11:08 -0800 (PST) MIME-Version: 1.0 References: <20210204150100.GE20815@willie-the-truck> <20210204163721.91295-1-lecopzer@gmail.com> <20210205171859.GE22665@willie-the-truck> In-Reply-To: <20210205171859.GE22665@willie-the-truck> From: Lecopzer Chen Date: Sat, 6 Feb 2021 02:10:56 +0800 Message-ID: Subject: Re: [PATCH v2 1/4] arm64: kasan: don't populate vmalloc area for CONFIG_KASAN_VMALLOC To: Will Deacon Cc: Andrew Morton , Andrey Konovalov , ardb@kernel.org, aryabinin@virtuozzo.com, broonie@kernel.org, Catalin Marinas , dan.j.williams@intel.com, Dmitry Vyukov , Alexander Potapenko , gustavoars@kernel.org, kasan-dev@googlegroups.com, Jian-Lin Chen , linux-arm-kernel , Linux Kernel Mailing List , linux-mediatek@lists.infradead.org, linux-mm@kvack.org, linux@roeck-us.net, robin.murphy@arm.com, rppt@kernel.org, tyhicks@linux.microsoft.com, vincenzo.frascino@arm.com, yj.chiang@mediatek.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: AA94E40001FF X-Stat-Signature: u5q4wm9rrk67u7oocruryubkjk4iozbj Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf02; identity=mailfrom; envelope-from=""; helo=mail-vk1-f181.google.com; client-ip=209.85.221.181 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1612548667-932447 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: Will Deacon =E6=96=BC 2021=E5=B9=B42=E6=9C=886=E6=97=A5 = =E9=80=B1=E5=85=AD =E4=B8=8A=E5=8D=881:19=E5=AF=AB=E9=81=93=EF=BC=9A > > On Fri, Feb 05, 2021 at 12:37:21AM +0800, Lecopzer Chen wrote: > > > > > On Thu, Feb 04, 2021 at 10:46:12PM +0800, Lecopzer Chen wrote: > > > > > On Sat, Jan 09, 2021 at 06:32:49PM +0800, Lecopzer Chen wrote: > > > > > > Linux support KAsan for VMALLOC since commit 3c5c3cfb9ef4da9 > > > > > > ("kasan: support backing vmalloc space with real shadow memory"= ) > > > > > > > > > > > > Like how the MODULES_VADDR does now, just not to early populate > > > > > > the VMALLOC_START between VMALLOC_END. > > > > > > similarly, the kernel code mapping is now in the VMALLOC area a= nd > > > > > > should keep these area populated. > > > > > > > > > > > > Signed-off-by: Lecopzer Chen > > > > > > --- > > > > > > arch/arm64/mm/kasan_init.c | 23 ++++++++++++++++++----- > > > > > > 1 file changed, 18 insertions(+), 5 deletions(-) > > > > > > > > > > > > diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_i= nit.c > > > > > > index d8e66c78440e..39b218a64279 100644 > > > > > > --- a/arch/arm64/mm/kasan_init.c > > > > > > +++ b/arch/arm64/mm/kasan_init.c > > > > > > @@ -214,6 +214,7 @@ static void __init kasan_init_shadow(void) > > > > > > { > > > > > > u64 kimg_shadow_start, kimg_shadow_end; > > > > > > u64 mod_shadow_start, mod_shadow_end; > > > > > > + u64 vmalloc_shadow_start, vmalloc_shadow_end; > > > > > > phys_addr_t pa_start, pa_end; > > > > > > u64 i; > > > > > > > > > > > > @@ -223,6 +224,9 @@ static void __init kasan_init_shadow(void) > > > > > > mod_shadow_start =3D (u64)kasan_mem_to_shadow((void *)MODULES= _VADDR); > > > > > > mod_shadow_end =3D (u64)kasan_mem_to_shadow((void *)MODULES_E= ND); > > > > > > > > > > > > + vmalloc_shadow_start =3D (u64)kasan_mem_to_shadow((void *)VMA= LLOC_START); > > > > > > + vmalloc_shadow_end =3D (u64)kasan_mem_to_shadow((void *)VMALL= OC_END); > > > > > > + > > > > > > /* > > > > > > * We are going to perform proper setup of shadow memory. > > > > > > * At first we should unmap early shadow (clear_pgds() call b= elow). > > > > > > @@ -241,12 +245,21 @@ static void __init kasan_init_shadow(void= ) > > > > > > > > > > > > kasan_populate_early_shadow(kasan_mem_to_shadow((void *)PAGE_= END), > > > > > > (void *)mod_shadow_start); > > > > > > - kasan_populate_early_shadow((void *)kimg_shadow_end, > > > > > > - (void *)KASAN_SHADOW_END); > > > > > > + if (IS_ENABLED(CONFIG_KASAN_VMALLOC)) { > > > > > > > > > > Do we really need yet another CONFIG option for KASAN? What's the= use-case > > > > > for *not* enabling this if you're already enabling one of the KAS= AN > > > > > backends? > > > >commit message > > > > As I know, KASAN_VMALLOC now only supports KASAN_GENERIC and also > > > > KASAN_VMALLOC uses more memory to map real shadow memory (1/8 of vm= alloc va). > > > > > > The shadow is allocated dynamically though, isn't it? > > > > Yes, but It's still a cost. > > > > > > There should be someone can enable KASAN_GENERIC but can't use VMAL= LOC > > > > due to memory issue. > > > > > > That doesn't sound particularly realistic to me. The reason I'm pushi= ng here > > > is because I would _really_ like to move to VMAP stack unconditionall= y, and > > > that would effectively force KASAN_VMALLOC to be set if KASAN is in u= se. > > > > > > So unless there's a really good reason not to do that, please can we = make > > > this unconditional for arm64? Pretty please? > > > > I think it's fine since we have a good reason. > > Also if someone have memory issue in KASAN_VMALLOC, > > they can use SW_TAG, right? > > > > However the SW_TAG/HW_TAG is not supported VMALLOC yet. > > So the code would be like > > > > if (IS_ENABLED(CONFIG_KASAN_GENERIC)) > > Just make this CONFIG_KASAN_VMALLOC, since that depends on KASAN_GENERIC. OK, this also make sense. My first thought was that selecting KASAN_GENERIC implies VMALLOC in arm64 is a special case so this need well documented. I'll document this in the commit message of Kconfig patch to avoid messing up the code here. I'm going to send V3 patch, thanks again for your review. BRs, Lecopzer