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=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 764FBC433E0 for ; Thu, 4 Feb 2021 18:41:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0086064DE1 for ; Thu, 4 Feb 2021 18:41:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0086064DE1 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 776E66B0006; Thu, 4 Feb 2021 13:41:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 701186B006E; Thu, 4 Feb 2021 13:41:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5EF486B0070; Thu, 4 Feb 2021 13:41:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0186.hostedemail.com [216.40.44.186]) by kanga.kvack.org (Postfix) with ESMTP id 4ABE16B0006 for ; Thu, 4 Feb 2021 13:41:47 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 1718A180AD80F for ; Thu, 4 Feb 2021 18:41:47 +0000 (UTC) X-FDA: 77781454254.09.cat81_3c0994d275de Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin09.hostedemail.com (Postfix) with ESMTP id F2C63180AD817 for ; Thu, 4 Feb 2021 18:41:46 +0000 (UTC) X-HE-Tag: cat81_3c0994d275de X-Filterd-Recvd-Size: 5935 Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Thu, 4 Feb 2021 18:41:46 +0000 (UTC) Received: by mail-pj1-f48.google.com with SMTP id d2so2322939pjs.4 for ; Thu, 04 Feb 2021 10:41:46 -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; bh=xPJcixL5B72ONNeQTUrd/Ds+3cwL/OzxhJxazJOwdWU=; b=hZEBnFadWKNcM22cVRU/a7ekIXxiGnvJaR2OBmXSBWA6MhsJnQ2IP0Ye4V2wat6Zrl 9XH7dXAdM9sS3FDL9bMNpEvQS1wZMWANxL4DrjDucQXa4SUlny92X0EuRxN1PAjCxlJC m2Rdnf0rreJ+30C4IzBRjr9B+mS3tkPN+k1uZbx/dni+WSpZMxs84jLLonRWdR1XL4iv Ol2ek6+pTFzt6KDgTWX+NVfz71eWtviLUCDaPXTDq6+0htUPSE9svu9bOcCSNrFn7Ufb YmAsPAVPCxvO32sPjMwPhd6eq4IPf/91C/Uugg+0biZoHhKZNN6+wyPWEY1UtAdmpX65 uTDQ== 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; bh=xPJcixL5B72ONNeQTUrd/Ds+3cwL/OzxhJxazJOwdWU=; b=dXtY296Zq2E6ft3e3wtAFRP/aSgUagxmF0wh3IU4jM//IYk6m+SoXBj9AIaejlhIyI P57QEcTRTaZunah20330E8M5Gx2q02YhKA1cfTiEmPXT63/ewaOCF1uYU+9rihUVqQWF KMfIzlkmlX7a6GAeWg4O8rwNAb80IwP2IpXC19VL/DHMZFteY/D8kx45jCI0mPFyuPF0 LshlU4dwBKphdJLJ4bCYBGsjSENF4YdX0sTkBZA2cakUxALyrcBs9g1JZiBKAr9Nhcvv mIuCbmiSNZQ1RVY0cPwkjOC4XpGGIzeKCI3Nvyy1dDJsr6SMN5vaozDjn1OgvuVBYoCn TzbQ== X-Gm-Message-State: AOAM5323KTrgjvF73GkJUP7puzUA76v8HTIratfZT9yD3ZwT+PtFC1Ar HPi/upqDJNVql/VrmMJcdypkQbAzpgNm+DJkEYE= X-Google-Smtp-Source: ABdhPJzy/LIgldY2il/NtwAfXOaYXEinArlc3vM117wT2mWj8AdIkX1bTtfJpk8Qa6r89tNQKFjtw0VzqsMn2rxOEpY= X-Received: by 2002:a17:90a:7787:: with SMTP id v7mr298480pjk.81.1612464105539; Thu, 04 Feb 2021 10:41:45 -0800 (PST) MIME-Version: 1.0 References: <20210204124914.GC20468@willie-the-truck> <20210204155346.88028-1-lecopzer@gmail.com> <20210204175659.GC21303@willie-the-truck> In-Reply-To: <20210204175659.GC21303@willie-the-truck> From: Lecopzer Chen Date: Fri, 5 Feb 2021 02:41:34 +0800 Message-ID: Subject: Re: [PATCH v2 0/4] arm64: kasan: support 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" 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 11:53:46PM +0800, Lecopzer Chen wrote: > > > 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") > > > > > > > > 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 arm64 > > > > by not to populate the vmalloc area except for kimg address. > > > > > > 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 > > | | > > | | > > | | <= non-mapping > > | | > > | | > > |-----------| > > |///////////|<- kimage shadow with page table mapping. > > |-----------| > > | | > > | | <= non-mapping > > | | > > ------------- vmalloc_shadow_end > > |00000000000| > > |00000000000| <= 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. > > Indeed, but the question I'm asking is what happens when an on-demand shadow > allocation from vmalloc overlaps with the shadow that we allocated early for > the kernel image? > > Sounds like I have to go and read the code... oh, sorry I misunderstood your question. FWIW, I think this won't happend because this mean vmalloc() provides va which already allocated by kimg, as I know, vmalloc_init() will insert early allocated vma into its vmalloc rb tree , and this early allocated vma will include kernel image. After quick review of mm init code, this early allocated for vma is at map_kernel() in arch/arm64/mm/mmu.c BRs Lecopzer