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=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 1FFCBC433DF for ; Mon, 6 Jul 2020 13:09:58 +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 E124620724 for ; Mon, 6 Jul 2020 13:09:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="m0xA8Wn0"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="W9rW/V4z" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E124620724 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.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=WKkJOQ3kiAJ03sC+fRnZPsjEEsxf7Ik3F5ZoUeuVZmY=; b=m0xA8Wn08OWdZ4xRUzwjE651z JOuUMB1ZlXaMqH5m7qhKGBWifAG5HweQFmaxAumKfOEdvzxz7SgFnjGdDkgyvJ7tamf6J0gyos892 ft6KIPi78+6MSwp7DnH8oExrt/6jyBXkumG3Efoq3l0B2oGJenmld8mtZc24IRtyO4WkrgCPxhK0d pWpj8TGlq4U8cRWgH+/Aio9WZXKa81/pfHVPUyxAprILqFdbmwx35Q5SefBOfD3B9oPkKfvCnKMZ0 Mx/+bw5PswmCVDzD5ZUJFLR6QQ0Ri77Wpdf+E50SqUyCLEWcAsH8fvRMqcdkCniNuQuUENpiH2W2a ovHBNC5EA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jsQrC-0004LY-Ql; Mon, 06 Jul 2020 13:08:26 +0000 Received: from mail-lj1-x244.google.com ([2a00:1450:4864:20::244]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jsQrB-0004Kx-5p for linux-arm-kernel@lists.infradead.org; Mon, 06 Jul 2020 13:08:25 +0000 Received: by mail-lj1-x244.google.com with SMTP id h22so38091203lji.9 for ; Mon, 06 Jul 2020 06:08:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jw4gWNskk+6UTmh34MGO6F4fqEg1zX6zJF/BoVSwRsg=; b=W9rW/V4zZghU31/WO1dYxRZB/GLj94h1+EfNoW7WZq7aPgIvtzAS6IOZYqSu1TDzpx k2qXk7uzcsmuujMd/xX1M1w566rTf5QIBHe15cYLAeiaTREd0hbk0BjDUiRwBudsK7+c L1nWrLQYntpRdots7pcUHqk4UGoFxfdwsyPXswOpJWwcDqu/oD+McxDttyTJTaClLzKi vu9oBBau4LuY929peEHyFZMc3RlJfVyRrPwEXOSCq7gLPMs7jn5lYWF1PU1ybeodQQvj /Lx8pXwyUEHHIQIY7/IYsuOApR6k+RT1BNu579/9rPVLVfF1ZqrmYWCtERvNvstl6Wxv EIvQ== 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=jw4gWNskk+6UTmh34MGO6F4fqEg1zX6zJF/BoVSwRsg=; b=dZ5AgJbNm9uJ+X2JD2ImC1eGAKjwEPpiOXVqep5rIn0SN/O1fsKSYCRC2J3m9viAy8 rbyeAEzQ4iezgBHFOPZSjdxgD4ygbvbAFoChZHuHDor9KcMwt98vXyDwaE8+0NT0rjlH x9IarRv/oMfvLUJsUYTJfYXnQJQF+Vltp+rh/22JfDRSQwVvimJKzZ7NRYMubfnnNnQg 52miPeSvJdhIA8PWSCOkzmo84I6kdnMWToL7Kc2riS3f6sZrKmxAk1FgOmdBhFcPxC8L skLIxUJ5j8Do5ufbdQ7xRa402W/dQpJdtRSi24F01JCfk4H9buuuFe6KNOk9MD1Yg+fC mkRA== X-Gm-Message-State: AOAM530/PbRJuF2QNtLz1SX1BQgnSleCXVGD8pwHjscwwj0rxAKhzDX8 jLClk/sD+PmvFqWdZRFdBq7iBEpu5+vzWSCLDsHjJNyeAco/9Q== X-Google-Smtp-Source: ABdhPJyy71NUoHtU8tXzHiC+YWshlnOPRAttgv5KUXuKV3+W6B92qVbQLaIOsKhgik55BSfwFjA/DOmE4bwD6/wR7V8= X-Received: by 2002:a2e:9a4d:: with SMTP id k13mr5599019ljj.283.1594040903871; Mon, 06 Jul 2020 06:08:23 -0700 (PDT) MIME-Version: 1.0 References: <20200630133736.231220-1-linus.walleij@linaro.org> <74eec7fa-6e6f-09ba-acd4-65a976117831@gmail.com> <89cd5038-8dfb-bddf-da1d-b1f412158ae4@gmail.com> In-Reply-To: From: Linus Walleij Date: Mon, 6 Jul 2020 15:08:13 +0200 Message-ID: Subject: Re: [PATCH 0/5 v11] KASan for Arm To: Ard Biesheuvel X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200706_090825_299835_B0A02D3A X-CRM114-Status: GOOD ( 16.16 ) 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: Florian Fainelli , Arnd Bergmann , Abbott Liu , 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 Thu, Jul 2, 2020 at 1:03 AM Ard Biesheuvel wrote: > Florian: > > Not that I can think of, the memory is mapped at PA 0x0000_0000 all the > > way to 0xbfff_ffff and then all other memory is mapped at PA > > 0x1_0000_0000 and aboved. > > OK, so assuming kasan_early_init() backs the entire shadow region with > zero pages correctly, we are losing the mapping somewhere between > there and kasan_init(), and there are quite a number of > create_mapping() calls in the meantime. > > So if you have cycles to spend on this, do you mind instrumenting > create_mapping() and see whether any of the ranges that are > (re`)mapped come within 2 MB of bc800000-bc9fffff? Hm. What I can think of is this code I have introduced in one of the patches: +#ifdef CONFIG_KASAN + /* + * KASan's shadow memory inserts itself between the TASK_SIZE + * and MODULES_VADDR. Do not clear the KASan shadow memory mappings. + */ + for (addr = 0; addr < KASAN_SHADOW_START; addr += PMD_SIZE) + pmd_clear(pmd_off_k(addr)); + /* + * Skip over the KASan shadow area. KASAN_SHADOW_END is sometimes + * equal to MODULES_VADDR and then we exit the pmd clearing. If we + * are using a thumb-compiled kernel, there there will be 8MB more + * to clear as KASan always offset to 16 MB below MODULES_VADDR. + */ + for (addr = KASAN_SHADOW_END; addr < MODULES_VADDR; addr += PMD_SIZE) + pmd_clear(pmd_off_k(addr)); +#else for (addr = 0; addr < MODULES_VADDR; addr += PMD_SIZE) pmd_clear(pmd_off_k(addr)); +#endif If you just augment this to clear the pmd:s for all the memory including the 8 MB not utilized when using thumb, what happens? I.e. just delete the special case for CONFIG_KASAN with al ifdef and else endif and have it be: for (addr = 0; addr < MODULES_VADDR; addr += PMD_SIZE) pmd_clear(pmd_off_k(addr)); This is what the patch used to look like but I introduced that this "hole" be skipped over, maybe something is using it? Yours, Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel