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=-3.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT 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 9748BC433DB for ; Thu, 4 Feb 2021 15:53:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 39C1C64F64 for ; Thu, 4 Feb 2021 15:53:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 39C1C64F64 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 957F16B0005; Thu, 4 Feb 2021 10:53:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8E0EB6B0006; Thu, 4 Feb 2021 10:53:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7CFF86B007E; Thu, 4 Feb 2021 10:53:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0002.hostedemail.com [216.40.44.2]) by kanga.kvack.org (Postfix) with ESMTP id 637506B0005 for ; Thu, 4 Feb 2021 10:53:58 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 22E44180AD815 for ; Thu, 4 Feb 2021 15:53:58 +0000 (UTC) X-FDA: 77781031356.23.cow85_2b14795275dd Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin23.hostedemail.com (Postfix) with ESMTP id F2AE937604 for ; Thu, 4 Feb 2021 15:53:57 +0000 (UTC) X-HE-Tag: cow85_2b14795275dd X-Filterd-Recvd-Size: 5161 Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Thu, 4 Feb 2021 15:53:57 +0000 (UTC) Received: by mail-pg1-f177.google.com with SMTP id o7so2414830pgl.1 for ; Thu, 04 Feb 2021 07:53:57 -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=12TvnDbFoHozjXEBq3jhYOc5BE9nWZn0P3eT299I/9M=; b=NinYrz5HwaCb0qq/rEnNwOPx6QmtQi63UUzFzsXFLnUBHeZC1H0vd4gdNitL8ljpn7 JgbnHSKWmW8zBYdCVeLnOw62uOaK2xAOYM5qaGXVX2cObM96tsJwsghylpKX5J2JmCEp zRZWWXLSEb3bhPr4fAPlOfAWOKx0lAIs3W3L/cAwvOWXKLWBeEF8oDrsB5jh89QZs1ha zUttQr9P5McciU0O78xQjpF+8TJWdQuJSktoRmHxX2bKbS+oXsw9MGpdGrIvcgmuK6J6 /DcDhIkd+cjexFi1QS9deq9KnoqL3e7307opKt+JWr3j7i+Ax6lbN3bP3zMbx4Lso8hf HEkA== 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=12TvnDbFoHozjXEBq3jhYOc5BE9nWZn0P3eT299I/9M=; b=GSR/LfDFf4GZ3UIjKJOH8iP2qJKkYAiFn/GnNdXiNYOyBAM8l/lC/nnJ1MSo9jlKRu Eip9zZenGSgawppE5isRGWzkx8qxJBr12lZNDxyJH/hoPU29HfQJt97jPFXIX6ITtpkV gMYNyDGR6qidoYqHgVSHe7yKTG1E4ocSr2s6ZJFrVhI1roH6AvRL2cskb9eELT/niz/h +d6kzVEQ5ztFMO2qVxa5di+a1/OkcXGpP+S96R7OOQxJojNg6/Qs9hCaJSTqnm+xnAdK lIlamp+mP4hYl0s8rF92oCTXfS1cnGKUmdkp540aMIQYqGUH1tAnIds+cixy2aPqP4Sp XXRw== X-Gm-Message-State: AOAM53343/YME7nfWisWCJnX3X8/zWB/T4IllHLkddVhC05gwtPA0U8U onoRLVjncXRSrDVTIlJSCEA= X-Google-Smtp-Source: ABdhPJxBXdR4q9H553UCiCPpdlcKwZ6b4yXIEmQNTn2cfq/9NXQmnXeoTexpuI1RuIEGOoKpWIvuPw== X-Received: by 2002:a63:105e:: with SMTP id 30mr9541231pgq.24.1612454036561; Thu, 04 Feb 2021 07:53:56 -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 16sm5580890pjc.28.2021.02.04.07.53.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Feb 2021 07:53:55 -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 0/4] arm64: kasan: support CONFIG_KASAN_VMALLOC Date: Thu, 4 Feb 2021 23:53:46 +0800 Message-Id: <20210204155346.88028-1-lecopzer@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210204124914.GC20468@willie-the-truck> References: <20210204124914.GC20468@willie-the-truck> MIME-Version: 1.0 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 Sat, Jan 09, 2021 at 06:32:48PM +0800, Lecopzer Chen wrote: > > Linux supports KAsan for VMALLOC since commit 3c5c3cfb9ef4da9 > > ("kasan: support backing vmalloc space with real shadow memory") > >=20 > > Acroding to how x86 ported it [1], they early allocated p4d and pgd, > > but in arm64 I just simulate how KAsan supports MODULES_VADDR in arm6= 4 > > by not to populate the vmalloc area except for kimg address. >=20 > The one thing I've failed to grok from your series is how you deal with > vmalloc allocations where the shadow overlaps with the shadow which has > already been allocated for the kernel image. Please can you explain? The most key point is we don't map anything in the vmalloc shadow address= . So we don't care where the kernel image locate inside vmalloc area. kasan_map_populate(kimg_shadow_start, kimg_shadow_end,...) Kernel image was populated with real mapping in its shadow address. I `bypass' the whole shadow of vmalloc area, the only place you can find about vmalloc_shadow is kasan_populate_early_shadow((void *)vmalloc_shadow_end, (void *)KASAN_SHADOW_END); ----------- vmalloc_shadow_start | | | |=20 | | <=3D non-mapping | | | | |-----------| |///////////|<- kimage shadow with page table mapping. |-----------| | | | | <=3D non-mapping | | ------------- vmalloc_shadow_end |00000000000| |00000000000| <=3D Zero shadow |00000000000| ------------- KASAN_SHADOW_END vmalloc shadow will be mapped 'ondemend', see kasan_populate_vmalloc() in mm/vmalloc.c in detail. So the shadow of vmalloc will be allocated later if anyone use its va. BRs, Lecopzer