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=-4.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 90FA3C433DF for ; Wed, 1 Jul 2020 08:34:38 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 64DF220722 for ; Wed, 1 Jul 2020 08:34:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="h2BT31ZV"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Fc+YvVXu" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 64DF220722 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=WMw+rPSg8aTofUqkF3s1f6TFfA8QQt3QjrAZYWUNny4=; b=h2BT31ZV2SSqT50isyNvkjetW 5dxWvF5UCjZjGIMAGhNBAEdsJb9FeU3yujrWbV64m9THMUd609FSAKASZhpU0HIcmxdSnslYDoNo0 khaQ1EXY69WGeCM7pTjQ/kU4Sj9nPGmczobxTkPpH4sqguo8U2bSs0MkpH0IRO7tcJdboFgxZR5EP wLaVpwiaCwITF+k+FOj2tn9yfJooVNQ2fGQD9iqRok1v0LGYLIUCFb+Y9ct4hKC/K359+QnMSq5Q5 pnpXhdclkhddDmebiwHSROuziNsNPVBqppJAjB6/CsBKbQ0atFWEwDhBNG1pons4h1RuLNUYBnoS5 Lol5xC70A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqYB5-0000tX-O0; Wed, 01 Jul 2020 08:33:11 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqYB2-0000sS-6c for linux-arm-kernel@lists.infradead.org; Wed, 01 Jul 2020 08:33:09 +0000 Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com [209.85.210.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BAD222074D for ; Wed, 1 Jul 2020 08:33:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593592385; bh=zcj9dYp9W1qAmJ7p2Zs4p9tYWAdDoabR5Ujs+XdVnCE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Fc+YvVXuL2pbupwTqL6V9RsWvd7DANirtBgVXmjR5AwJjUctQnxbvkYDnf0n9TcVy KYnlMWh8eH9nfUSYZqb6VW1V04qAs4DpHu/dpUz2HMBTNC6PuRq35Pz+I4ufJm6cdb fmcJqc8DJShZLpC7lpIZoEfSouaV3mKpyxHaZps0= Received: by mail-ot1-f43.google.com with SMTP id w17so12937578otl.4 for ; Wed, 01 Jul 2020 01:33:05 -0700 (PDT) X-Gm-Message-State: AOAM533mgSOX10B3ffYG5ErsFkf5tYsKYFP5Vf1z/8re3PgT9yLl91KX V555sdvHcMbCiFZnNcE7OfN+XkWmhz2Rjn67meI= X-Google-Smtp-Source: ABdhPJwJFJh1W9r0yjh8O8MgkevEsBHtUJ7lHnQUnTr5wtPK0hiCE7U13MDiA0UKuXRrs6KtuFzfY+Zr7PguULI3fRY= X-Received: by 2002:a9d:688:: with SMTP id 8mr21459487otx.108.1593592384977; Wed, 01 Jul 2020 01:33:04 -0700 (PDT) MIME-Version: 1.0 References: <20200630133736.231220-1-linus.walleij@linaro.org> <74eec7fa-6e6f-09ba-acd4-65a976117831@gmail.com> In-Reply-To: From: Ard Biesheuvel Date: Wed, 1 Jul 2020 10:32:53 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/5 v11] KASan for Arm To: Florian Fainelli X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200701_043308_411370_0AD7D906 X-CRM114-Status: GOOD ( 53.60 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Arnd Bergmann , Abbott Liu , Linus Walleij , Russell King , Mike Rapoport , Andrey Ryabinin , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 1 Jul 2020 at 09:43, Ard Biesheuvel wrote: > > On Wed, 1 Jul 2020 at 06:53, Florian Fainelli wrote: > > > > > > > > On 6/30/2020 2:41 PM, Ard Biesheuvel wrote: > > > On Tue, 30 Jun 2020 at 15:39, Linus Walleij wrote: > > >> > > >> This is the v11 version of the KASan patches for ARM. > > >> > > >> The main changes from the v10 version is: > > >> > > >> - LPAE now compiles and works again, at least Versatile Express > > >> Cortex A15 TC1 in QEMU (which is the LPAE system I have > > >> access to). > > >> > > >> - Rewrite some of the page directory initialization after > > >> helpful feedback from Mike Rapoport and Russell King. > > >> > > >> Also minor improvements to commit messages and comments > > >> in the code so it is clear (for most cases I hope) why > > >> some ifdefs etc are there. > > >> > > >> All tested platforms from ARMv4 thru ARMv7 work fine. I > > >> have not been able to re-test with the Qualcomm DragonBoard > > >> APQ8060 yet, but I suspect the problem there is that the > > >> DT parser code reaches out into non-kernel memory and > > >> needs some de-instrumentation, possibly combined with the > > >> memory holding the device tree getting corrupted or reused > > >> before we have a chance to parse it. > > >> > > >> Abbott Liu (1): > > >> ARM: Define the virtual space of KASan's shadow region > > >> > > >> Andrey Ryabinin (3): > > >> ARM: Disable KASan instrumentation for some code > > >> ARM: Replace string mem* functions for KASan > > >> ARM: Enable KASan for ARM > > >> > > >> Linus Walleij (1): > > >> ARM: Initialize the mapping of KASan shadow memory > > >> > > > > > > Hi, > > > > > > I needed the changes below to make this work on a 16 core GICv3 > > > QEMU/KVM vm with 8 GB of RAM > > > > > > Without masking start, I get a strange error where kasan_alloc_block() > > > runs out of memory, probably because one of the do..while stop > > > conditions fails to trigger and we loop until we run out of lowmem. > > > > > > The TLB flush is really essential to make any of these page table > > > modifications take effect right away, and strange things can happen if > > > you don't. I also saw a crash in the DT unflatten code without this > > > change, but that is probably because it is simply the code that runs > > > immediately after. > > > > > > If you see anything like > > > > > > Unable to handle kernel paging request at virtual address b744077c > > > [b744077c] *pgd=80000040206003, *pmd=6abf5003, *pte=c000006abb471f > > > > > > where the CPU faults on an address that appears to have a valid > > > mapping at each level, it means that the page table walker was using a > > > stale TLB entry to do the translation, triggered a fault and when we > > > look at the page tables in software, everything looks like it is > > > supposed to. > > > > Thanks Ard, this allows me to boot successfully to a prompt on a BCM7278 > > system whereas we would have an error before while unflattening the DT. > > > > Now there are still other systems that fail booting with the error log > > attached previously, but it is not clear yet to me why this is happening > > as it does not seem to depend on the memory ranges only as I initially > > thought. > > It seems to me that for LPAE, we are not copying enough of the level 2 > early shadow tables: a level 2 table covers 512 MB, which is exactly > the size of the KASAN shadow region for a 4 GB address space. However, > the shadow region is not 512 MB aligned, and so the early shadow > necessarily covers two level 2 tables. Could you try the following > please? > > diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c > index 535dce42e59d..3c9c37a59b57 100644 > --- a/arch/arm/mm/kasan_init.c > +++ b/arch/arm/mm/kasan_init.c > @@ -27,7 +27,7 @@ > > static pgd_t tmp_pgd_table[PTRS_PER_PGD] __initdata __aligned(PGD_SIZE); > > -pmd_t tmp_pmd_table[PTRS_PER_PMD] __page_aligned_bss; > +static pmd_t tmp_pmd_table[2][PTRS_PER_PMD] __page_aligned_bss; > > static __init void *kasan_alloc_block(size_t size, int node) > { > @@ -231,13 +231,15 @@ void __init kasan_init(void) > * to the proper swapper_pg_dir. > */ > memcpy(tmp_pgd_table, swapper_pg_dir, sizeof(tmp_pgd_table)); > -#ifdef CONFIG_ARM_LPAE > - memcpy(tmp_pmd_table, > - pgd_page_vaddr(*pgd_offset_k(KASAN_SHADOW_START)), > - sizeof(tmp_pmd_table)); > - set_pgd(&tmp_pgd_table[pgd_index(KASAN_SHADOW_START)], > - __pgd(__pa(tmp_pmd_table) | PMD_TYPE_TABLE | L_PGD_SWAPPER)); > -#endif > + if (IS_ENABLED(CONFIG_ARM_LPAE)) { > + memcpy(tmp_pmd_table, > + pgd_page_vaddr(*pgd_offset_k(KASAN_SHADOW_START)), > + sizeof(tmp_pmd_table)); > + set_pgd(&tmp_pgd_table[pgd_index(KASAN_SHADOW_START)], > + __pgd(__pa(&tmp_pmd_table[0]) | PMD_TYPE_TABLE > | L_PGD_SWAPPER)); > + set_pgd(&tmp_pgd_table[pgd_index(KASAN_SHADOW_START) + 1], > + __pgd(__pa(&tmp_pmd_table[1]) | PMD_TYPE_TABLE > | L_PGD_SWAPPER)); > + } > cpu_switch_mm(tmp_pgd_table, &init_mm); > clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END); Hum maybe not. KASAN_SHADOW_START != KASAN_SHADOW_OFFSET in this case, and AIUI, the kernel's KASAN shadow region is [b6e00000, bf000000), which falls entirely inside a naturally aligned 512 MB region. IOW, pgd_index(KASAN_SHADOW_START) == pgd_index(KASAN_SHADOW_END), and we should probably add a build_bug_on() there to ensure that this remains the case. However, your crash log does suggest that no early shadow mapping exists for address 0xecff0000 (shadowed at 0xbc9ffe00), and I suspect that the clear_pgds() call is implicated in this, but I am not sure how exactly. In any case, I found another issue: [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000040000000-0x00000000ffab1fff] [ 0.000000] node 0: [mem 0x00000000ffab2000-0x00000000ffc73fff] [ 0.000000] node 0: [mem 0x00000000ffc74000-0x00000000ffffffff] ... [ 0.000000] kasan: populating shadow for b7000000, bd000000 [ 0.000000] kasan: populating shadow for aef56400, bd000000 [ 0.000000] kasan: populating shadow for aef8e800, bd000000 [ 0.000000] kasan: populating shadow for b6f00000, b7000000 i.e., the two highmem ranges are not disregarded as they should, due to the bogus __va() translations and the truncation by the (void *) casts. Fix below: diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c index 535dce42e59d..d8b2b93cfee5 100644 --- a/arch/arm/mm/kasan_init.c +++ b/arch/arm/mm/kasan_init.c @@ -248,10 +248,12 @@ void __init kasan_init(void) void *start = __va(reg->base); void *end = __va(reg->base + reg->size); + if (reg->base > arm_lowmem_limit) + continue; if (reg->base + reg->size > arm_lowmem_limit) end = __va(arm_lowmem_limit); if (start >= end) - break; + continue; create_mapping((unsigned long)kasan_mem_to_shadow(start), (unsigned long)kasan_mem_to_shadow(end), _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel