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 2C0BFC433DB for ; Sat, 20 Mar 2021 13:01:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8F68C6196F for ; Sat, 20 Mar 2021 13:01:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8F68C6196F 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 DB4086B0083; Sat, 20 Mar 2021 09:01:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D54086B0085; Sat, 20 Mar 2021 09:01:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C1AB58D0002; Sat, 20 Mar 2021 09:01:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id A5B276B0083 for ; Sat, 20 Mar 2021 09:01:24 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 40A2A18239AA3 for ; Sat, 20 Mar 2021 13:01:24 +0000 (UTC) X-FDA: 77940263688.29.CAB3FD6 Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) by imf01.hostedemail.com (Postfix) with ESMTP id 554F6500242B for ; Sat, 20 Mar 2021 13:01:20 +0000 (UTC) Received: by mail-pj1-f48.google.com with SMTP id a22-20020a17090aa516b02900c1215e9b33so8049722pjq.5 for ; Sat, 20 Mar 2021 06:01:21 -0700 (PDT) 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=9ON3r+aiJR5Q+UUgakEzAMuWKjcsi9+uuz4/fBWDEro=; b=QZgnK16rXyq85ehDyAiQXZvR70iLXG5F0ewNKUe8pvMEOjHRjNFx/ZCmcXpTkz6m2E o51J3PDpJFFIlxyJ/tPi7hx0MNf338zs7jhG42/ym/TcxPnnowQMIUsCr9U+6LLxXjDn 7fcZJT1iFquSBRa24aLwPa1iXN+8Y+Ea668zFzLm6wWUJYF8JjGplr6MnerBT/b65cGu SNs/wRNJ7VGLoqwRHc0GPSNgQWmilhW+siP8nyr+A94M7oepd6rJ5lVgtitNPRpmwsdc rBQnZ0J+Vm7jtSK4gaNDhI2oKKOhszLw8dqHrxJUzDV4VmFHmTx8DO06GeaMhuqgiP8Q Pz1A== 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=9ON3r+aiJR5Q+UUgakEzAMuWKjcsi9+uuz4/fBWDEro=; b=tudlfK2M+9Gj/uJoo624yWrNtIZNZ8S73Y7enEX2qW7E8maZNUo9gTXkhV0ct0wamp VRgYVdzu9zA1Lq12+xqjMTtB2rYUAkJb2z6hSyy8cXdPbEb4k27JXI569aq3lz+1CMfF gfGglPtczm2jFcBBseFvEG3qUu3oIca4LjNReBbO6uGMKjjRAOKlMdq0ZdlG+w0VpUEg 5fTf6B3T7OZpqbckAgTj9ZgaMuiEt/2yN5iIMuXJK4inHos1eNZUhFsaxxQ8L9seFGME PwheEK83IxpaC0/7W83f6DVqdkQentQO9qNFOjwMI5gptapWAPycrNf+6kLfAcILKfy3 JHJg== X-Gm-Message-State: AOAM532LqBfMEg9A3N1Fc0jxLuCfrCANEJcvr2/XMDq1+Rm/JuDXIxXj 5lUmWC8NfIjnZc+eEjGW065uKhne1KPGk/oMvZc= X-Google-Smtp-Source: ABdhPJwu0PgawlU0aWRzBKCj1+2gsUvraBIaBwJWOXpTMjPRxKpSzNQ3z/8nQ5/HfHn5A1slZVncNDIhR+lGjrUS+Cg= X-Received: by 2002:a17:90a:4104:: with SMTP id u4mr3445045pjf.81.1616245278293; Sat, 20 Mar 2021 06:01:18 -0700 (PDT) MIME-Version: 1.0 References: <20210206083552.24394-1-lecopzer.chen@mediatek.com> <20210206083552.24394-2-lecopzer.chen@mediatek.com> <20210319173758.GC6832@arm.com> In-Reply-To: <20210319173758.GC6832@arm.com> From: Lecopzer Chen Date: Sat, 20 Mar 2021 21:01:07 +0800 Message-ID: Subject: Re: [PATCH v3 1/5] arm64: kasan: don't populate vmalloc area for CONFIG_KASAN_VMALLOC To: Catalin Marinas Cc: Lecopzer Chen , Linux Kernel Mailing List , linux-mm@kvack.org, kasan-dev@googlegroups.com, linux-arm-kernel , Will Deacon , dan.j.williams@intel.com, aryabinin@virtuozzo.com, Alexander Potapenko , Dmitry Vyukov , Andrew Morton , linux-mediatek@lists.infradead.org, yj.chiang@mediatek.com, ardb@kernel.org, Andrey Konovalov , broonie@kernel.org, linux@roeck-us.net, rppt@kernel.org, tyhicks@linux.microsoft.com, robin.murphy@arm.com, vincenzo.frascino@arm.com, gustavoars@kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 554F6500242B X-Stat-Signature: iikzmu3pas1wipasisciqgr3jfge71qj Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf01; identity=mailfrom; envelope-from=""; helo=mail-pj1-f48.google.com; client-ip=209.85.216.48 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616245280-93747 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, Mar 20, 2021 at 1:38 AM Catalin Marinas wrote: > > On Sat, Feb 06, 2021 at 04:35:48PM +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. > > > > Before: > > > > MODULE_VADDR: no mapping, no zoreo shadow at init > > VMALLOC_VADDR: backed with zero shadow at init > > > > After: > > > > MODULE_VADDR: no mapping, no zoreo shadow at init > > VMALLOC_VADDR: no mapping, no zoreo shadow at init > > s/zoreo/zero/ > thanks! > > Thus the mapping will get allocated on demand by the core function > > of KASAN_VMALLOC. > > > > ----------- vmalloc_shadow_start > > | | > > | | > > | | <= non-mapping > > | | > > | | > > |-----------| > > |///////////|<- kimage shadow with page table mapping. > > |-----------| > > | | > > | | <= non-mapping > > | | > > ------------- vmalloc_shadow_end > > |00000000000| > > |00000000000| <= Zero shadow > > |00000000000| > > ------------- KASAN_SHADOW_END > > > > Signed-off-by: Lecopzer Chen > > --- > > arch/arm64/mm/kasan_init.c | 18 +++++++++++++----- > > 1 file changed, 13 insertions(+), 5 deletions(-) > > > > diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c > > index d8e66c78440e..20d06008785f 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_end; > > phys_addr_t pa_start, pa_end; > > u64 i; > > > > @@ -223,6 +224,8 @@ static void __init kasan_init_shadow(void) > > mod_shadow_start = (u64)kasan_mem_to_shadow((void *)MODULES_VADDR); > > mod_shadow_end = (u64)kasan_mem_to_shadow((void *)MODULES_END); > > > > + vmalloc_shadow_end = (u64)kasan_mem_to_shadow((void *)VMALLOC_END); > > + > > /* > > * We are going to perform proper setup of shadow memory. > > * At first we should unmap early shadow (clear_pgds() call below). > > @@ -241,12 +244,17 @@ 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 (kimg_shadow_start > mod_shadow_end) > > - kasan_populate_early_shadow((void *)mod_shadow_end, > > - (void *)kimg_shadow_start); > > Not something introduced by this patch but what happens if this > condition is false? It means that kimg_shadow_end < mod_shadow_start and > the above kasan_populate_early_shadow(PAGE_END, mod_shadow_start) > overlaps with the earlier kasan_map_populate(kimg_shadow_start, > kimg_shadow_end). In this case, the area between mod_shadow_start and kimg_shadow_end was mapping when kasan init. Thus the corner case is that module_alloc() allocates that range (the area between mod_shadow_start and kimg_shadow_end) again. With VMALLOC_KASAN, module_alloc() -> ... -> kasan_populate_vmalloc -> apply_to_page_range() will check the mapping exists or not and bypass allocating new mapping if it exists. So it should be fine in the second allocation. Without VMALLOC_KASAN, module_alloc() -> kasan_module_alloc() will allocate the range twice, first time is kasan_map_populate() and second time is vmalloc(), and this should have some problems(?). Now the only possibility that the module area can overlap with kimage should be KASLR on. I'm not sure if this is the case that really happens in KASLR, it depends on how __relocate_kernel() calculates kimage and how kaslr_earlt_init() decides module_alloc_base. > > + if (IS_ENABLED(CONFIG_KASAN_VMALLOC)) > > + 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); > > + } > > > > for_each_mem_range(i, &pa_start, &pa_end) { > > void *start = (void *)__phys_to_virt(pa_start); > > -- > > 2.25.1 > >