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=-13.5 required=3.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT 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 EE1DDC433E0 for ; Thu, 4 Feb 2021 16:37:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4DD4264F4E for ; Thu, 4 Feb 2021 16:37:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4DD4264F4E 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 C1A146B006E; Thu, 4 Feb 2021 11:37:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BA2326B0072; Thu, 4 Feb 2021 11:37:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A1C686B0075; Thu, 4 Feb 2021 11:37:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0098.hostedemail.com [216.40.44.98]) by kanga.kvack.org (Postfix) with ESMTP id 7E7E26B006E for ; Thu, 4 Feb 2021 11:37:34 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 40FC3180AD820 for ; Thu, 4 Feb 2021 16:37:34 +0000 (UTC) X-FDA: 77781141228.05.bat27_1809cca275dd Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id 26CC618033E43 for ; Thu, 4 Feb 2021 16:37:34 +0000 (UTC) X-HE-Tag: bat27_1809cca275dd X-Filterd-Recvd-Size: 7604 Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com [209.85.210.170]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Thu, 4 Feb 2021 16:37:33 +0000 (UTC) Received: by mail-pf1-f170.google.com with SMTP id x23so933470pfn.6 for ; Thu, 04 Feb 2021 08:37:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=nwObsRzKSVhqA/EbWV8d9m9v2JwQDreOVTF8iuaBQ+g=; b=Qs76dodtfk29vh9y2oWEdTMAEgX8pR7GDXBRZt11OnuF+F3yrCFpGCfE3EUSAGkLGg 5jkQJMKtoXCFCFsOw41yy0P24mbEQnUU/PN1vC734l1/K39+46+VS6bbscHzj2L55Whw FW22EBkyNiVCxmkNsXDYGEsP+zGH6f3LFIpXAoDhgixEHEseFXS8agAF7cSt15vBfmIu sa7oQOcvJtNzr/K6/r+vpvpUh+C2Mr6l1bM36mquA5Xn9VwjHxOLJnJ4Q3BcPgr4LZ4Y ey0TsDb+L/fowZ7+gofPOCsnCxtE2ihWeCgNDWMxadMu+izWumzDBNC7nofrD9894P78 GvUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=nwObsRzKSVhqA/EbWV8d9m9v2JwQDreOVTF8iuaBQ+g=; b=PDAS5TK6Ga4i/e+3fksIs2s3lY4dmqWOBvFXMwBzMpDWRy2HEt26IXloH1/5d5OZcR 9dCYj0ZeswIKk+AO5C/LvuK6X486Nq0ELNOe9zaZV9/KgXPXJozCSzpR0jVly93dsPad h3gzSmgQBO1d4drqeoyL82ET9aWsvVamVcjTF50p7/C/9VjglzI105gjZ3xHapu1XdvY 34E19t3NW1SliXU8ZzlQmaExA1R3MIkm/uOqqcvnH8BbUrhtPQfoAJklKSfqVMU9MPg5 gQ07nyMlgzGf9zcOA8r59aaLz4R8XTCHIeIvS2asKW9AtZ+XNQ/htxClSx59Svd7/tGg TyPg== X-Gm-Message-State: AOAM530veVvjHD7VpSW3UgKGicM7KpPPIleMZw+IwOxisqan5RAqbDJs DcHDTgcwKtYiaxf3FJcWWZo= X-Google-Smtp-Source: ABdhPJwYeZjRTrriYxBENEsGDiTCAauUg/JSwi9Ur6XUH/miSvOUu2eE8co0/Eh8tRvQGVqY8tG4fw== X-Received: by 2002:a62:e217:0:b029:1c1:59ed:ae73 with SMTP id a23-20020a62e2170000b02901c159edae73mr77195pfi.6.1612456652596; Thu, 04 Feb 2021 08:37:32 -0800 (PST) Received: from localhost.localdomain (61-230-45-44.dynamic-ip.hinet.net. [61.230.45.44]) by smtp.gmail.com with ESMTPSA id 9sm2371133pgw.61.2021.02.04.08.37.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Feb 2021 08:37:31 -0800 (PST) From: Lecopzer Chen To: will@kernel.org Cc: akpm@linux-foundation.org, andreyknvl@google.com, ardb@kernel.org, aryabinin@virtuozzo.com, broonie@kernel.org, catalin.marinas@arm.com, dan.j.williams@intel.com, dvyukov@google.com, glider@google.com, gustavoars@kernel.org, kasan-dev@googlegroups.com, lecopzer.chen@mediatek.com, lecopzer@gmail.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, 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 Subject: Re: [PATCH v2 1/4] arm64: kasan: don't populate vmalloc area for CONFIG_KASAN_VMALLOC Date: Fri, 5 Feb 2021 00:37:21 +0800 Message-Id: <20210204163721.91295-1-lecopzer@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210204150100.GE20815@willie-the-truck> References: <20210204150100.GE20815@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 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: > 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 and > > > > should keep these area populated. > > > > > > > > Signed-off-by: Lecopzer Chen > > > > --- > > > > =C2=A0arch/arm64/mm/kasan_init.c | 23 ++++++++++++++++++----- > > > > =C2=A01 file changed, 18 insertions(+), 5 deletions(-) > > > > > > > > diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_ini= t.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) > > > > =C2=A0{ > > > > =C2=A0 u64 kimg_shadow_start, kimg_shadow_end; > > > > =C2=A0 u64 mod_shadow_start, mod_shadow_end; > > > > + u64 vmalloc_shadow_start, vmalloc_shadow_end; > > > > =C2=A0 phys_addr_t pa_start, pa_end; > > > > =C2=A0 u64 i; > > > > > > > > @@ -223,6 +224,9 @@ static void __init kasan_init_shadow(void) > > > > =C2=A0 mod_shadow_start =3D (u64)kasan_mem_to_shadow((void *)MODU= LES_VADDR); > > > > =C2=A0 mod_shadow_end =3D (u64)kasan_mem_to_shadow((void *)MODULE= S_END); > > > > > > > > + vmalloc_shadow_start =3D (u64)kasan_mem_to_shadow((void *)VMALL= OC_START); > > > > + vmalloc_shadow_end =3D (u64)kasan_mem_to_shadow((void *)VMALLOC= _END); > > > > + > > > > =C2=A0 /* > > > > =C2=A0 =C2=A0* We are going to perform proper setup of shadow mem= ory. > > > > =C2=A0 =C2=A0* At first we should unmap early shadow (clear_pgds(= ) call below). > > > > @@ -241,12 +245,21 @@ static void __init kasan_init_shadow(void) > > > > > > > > =C2=A0 kasan_populate_early_shadow(kasan_mem_to_shadow((void *)PA= GE_END), > > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(void *)mod_shadow_start); > > > > - kasan_populate_early_shadow((void *)kimg_shadow_end, > > > > - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(void *)KASAN_SHADOW_END); > > > > + if (IS_ENABLED(CONFIG_KASAN_VMALLOC)) { > > > > > > Do we really need yet another CONFIG option for KASAN? What's the u= se-case > > > for *not* enabling this if you're already enabling one of the KASAN > > > backends? > > > > 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 vmal= loc 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 VMALLO= C > > due to memory issue. > > That doesn't sound particularly realistic to me. The reason I'm pushing= here > is because I would _really_ like to move to VMAP stack unconditionally,= and > that would effectively force KASAN_VMALLOC to be set if KASAN is in use= . > > So unless there's a really good reason not to do that, please can we ma= ke > 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)) /* explain the relationship between=20 * KASAN_GENERIC and KASAN_VMALLOC in arm64 * XXX: because we want VMAP stack.... */ kasan_populate_early_shadow((void *)vmalloc_shadow_end, (void *)KASAN_SHADOW_END); else { kasan_populate_early_shadow((void *)kimg_shadow_end, (void *)KASAN_SHADOW_END); if (kimg_shadow_start > mod_shadow_end) kasan_populate_early_shadow((void *)mod_shadow_end, (void *)kimg_shadow_start); } and the arch/arm64/Kconfig will add select KASAN_VMALLOC if KASAN_GENERIC Is this code same as your thought? BRs, Lecopzer