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=-6.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 67ABCC4338F for ; Wed, 11 Aug 2021 09:55:02 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 21BA460200 for ; Wed, 11 Aug 2021 09:55:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 21BA460200 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=rbgshBWs3zuj8jVAfXLrfws5VDnztfmBZErONMwe6Vk=; b=T0S2bV8pWaYqfS 0mUB5F2owZa8EoLOMtb8Yr7ve2ZzwGgoC74oCIDbiFMdO62qYKDZ9i+HaHrgKImoQ3M3/s53HeDNs fxKEzFoJqlOFyFjobp+hDNTGn5IC0AMYVeu1AIhhCPVjQBRimh+t2DGrRlhgPR+PSwBm+S6o8jWa7 ezSNv4A0WaSmpgw7KxkEgUX6hus2ivWbbk8/sr16cvhgHFgzzjjcQRw2nobDroOPot5fSfCOFZ3Zm 5R/PPz9TIpjKLtvaTKUJWF5FO/2UT610BrZOmhKZmvUulS9LUA7z2UBlQMAMg6F3hvMp/Cmnz6oKV Q53bA7nNWxr7zBdJ6YSQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mDkuW-006ROV-FU; Wed, 11 Aug 2021 09:52:33 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mDknI-006OeA-8o for linux-arm-kernel@lists.infradead.org; Wed, 11 Aug 2021 09:45:05 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id BD47E60FD9; Wed, 11 Aug 2021 09:45:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1628675103; bh=+2dTagUAInJEvuASDC1knwLJbE7mQJ7V5BFXKVEdmtE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=iBFrgb+/mSYVrc3hRbMR45K4JbwxCUVFBEbqgcu4bTf8KNz2SjZD9+tBYc8gCzt5H 8p6qL/qIoDrPrIqTbngT8qeeL6Q48/fArg+sfrW6Ebn3PF6s5s00X7oARxUPRHa9U+ xthM7rE1LwjU6YyQbrXXnxSfKSNgrLcvNktNXGWySvmI2mXGlWhZsxdCk3pP4yGZ97 oANt+l34wls0s81K0cUAe8Jy+/eQc/wBd2ZeL1Ctdj1oBYssUZunHzCNbV3i6HQsiN NvtKSNKUjMEHQOdCTC/e4ZBdkT6yvDydsJlPIZpfdMoER2zZzji0dJKcDmDzP5ePl3 FzL1lh89QhNRw== Date: Wed, 11 Aug 2021 10:44:58 +0100 From: Will Deacon To: Mark Rutland Cc: linux-arm-kernel@lists.infradead.org, anshuman.khandual@arm.com, ard.biesheuvel@linaro.org, catalin.marinas@arm.com, steve.capper@arm.com Subject: Re: [PATCH] arm64: head: avoid over-mapping in map_memory Message-ID: <20210811094457.GA4426@willie-the-truck> References: <20210810152756.23903-1-mark.rutland@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210810152756.23903-1-mark.rutland@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210811_024504_391910_B80481E1 X-CRM114-Status: GOOD ( 19.66 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Hi Mark, On Tue, Aug 10, 2021 at 04:27:56PM +0100, Mark Rutland wrote: > The `compute_indices` and `populate_entries` macros operate on inclusive > bounds, and thus the `map_memory` macro which uses them also operates > on inclusive bounds. > > We pass `_end` and `_idmap_text_end` to `map_memory`, but these are > exclusive bounds, and if one of these is sufficiently aligned (as a > result of kernel configuration, physical placement, and KASLR), then: > > * In `compute_indices`, the computed `iend` will be in the page/block *after* > the final byte of the intended mapping. > > * In `populate_entries`, an unnecessary entry will be created at the end > of each level of table. At the leaf level, this entry will map up to > SWAPPER_BLOCK_SIZE bytes of physical addresses that we did not intend > to map. > > As we may map up to SWAPPER_BLOCK_SIZE bytes more than intended, we may > violate the boot protocol and map physical address past the 2MiB-aligned > end address we are permitted to map. As we map these with Normal memory > attributes, this may result in further problems depending on what these > physical addresses correspond to. > > Fix this by subtracting one from the end address in both cases, such > that we always use inclusive bounds. For clarity, comments are updated > to more clearly document that the macros expect inclusive bounds. I think the comments are already clear for populate_entries and map_memory, so just adding something to compute_indices should suffice. As-is, your patch leaves populate_entries inconsistent with the others. That aside, I don't think any amount of comments will help because it's just plain weird for vend to be inclusive for map_memory, no? Given that both (all) callers got this wrong, I'd be inclined to say that map_memory should take an exclusive 'vend' as you'd normally expect and it can adjust it before using the helper macros (which should perhaps have 'inclusive' in their names). Although we currently preserve 'vend' in map_memory, that doesn't appear to be necessary so we can just move it to the list of clobbers in the comment nobody reads. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel