From patchwork Wed Mar 30 07:46:23 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 64639 Delivered-To: patch@linaro.org Received: by 10.112.199.169 with SMTP id jl9csp2444230lbc; Wed, 30 Mar 2016 00:48:13 -0700 (PDT) X-Received: by 10.98.67.76 with SMTP id q73mr10623478pfa.137.1459324093618; Wed, 30 Mar 2016 00:48:13 -0700 (PDT) Return-Path: Received: from bombadil.infradead.org (bombadil.infradead.org. [2001:1868:205::9]) by mx.google.com with ESMTPS id t9si4639028pfa.9.2016.03.30.00.48.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Mar 2016 00:48:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) client-ip=2001:1868:205::9; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) smtp.mailfrom=linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org; dmarc=fail (p=NONE dis=NONE) header.from=linaro.org Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1alAq7-0002kK-4t; Wed, 30 Mar 2016 07:46:55 +0000 Received: from mail-wm0-x235.google.com ([2a00:1450:400c:c09::235]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1alAq3-0002j0-CS for linux-arm-kernel@lists.infradead.org; Wed, 30 Mar 2016 07:46:52 +0000 Received: by mail-wm0-x235.google.com with SMTP id 20so58120607wmh.1 for ; Wed, 30 Mar 2016 00:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=o1F9HBGWOOTB7unMxDHyvB5kMFyx9z5Bssq+8iNZviI=; b=AqLkjPCxLAO92SJ7tbSa27npSIm7UjzLTfduuDUkM62MDb0nYmsA7K86tqVXMH0zYQ e5cnc76Q/hrAbN0mD+eUnfe7VSKPxrvgiAHrgINbIUMqasf0u6w0M3iioNIDM2THgrJg euB2vLnHt8qUpGm8InYF+3QNe/OcTNbSLmXgs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=o1F9HBGWOOTB7unMxDHyvB5kMFyx9z5Bssq+8iNZviI=; b=cIe8CvZ67X4h1Vuf+cm3dWLXw66VC4gwkDwtkVOVd9TOjHc+oerMkXkwIa6n7etE+w nYCIrZOSskRvXLZOxa/Ng9VpIpd1X5AvwmFj9wgWDyfaZPGfjl33bpgVaw+JfDHawq4j p3xOg00UZa6hvOkhuE8Y/ANwxGXt5TvnBPs2GjSkBvn7f9mpnsxIpHohTMdRsIUU2XeO L/5LpuaOaYUvL9tl2+fgGjuimjryUD3+LAqddW+pj4M4Yy8SUNHu2RSta4xEjvEkPe96 BWBtYx1NnRlkbNfEB88q9Y4spCDcXpAn1qunVW26HfyxxdBJrnbKIErjPw3nPJ8bu+C7 oxCA== X-Gm-Message-State: AD7BkJLp181vjVIiP2x59qzxAg0z4wYCFIKSWuEGDAEN3UJhzrWnhLu0F+zt6AIQTB3NmC1e X-Received: by 10.194.123.35 with SMTP id lx3mr7492387wjb.132.1459323988814; Wed, 30 Mar 2016 00:46:28 -0700 (PDT) Received: from localhost.localdomain ([195.55.142.58]) by smtp.gmail.com with ESMTPSA id ei9sm2480888wjd.40.2016.03.30.00.46.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 30 Mar 2016 00:46:28 -0700 (PDT) From: Ard Biesheuvel To: linux-efi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, matt@codeblueprint.co.uk Subject: [PATCH] efi/arm64: don't apply MEMBLOCK_NOMAP to UEFI memory map mapping Date: Wed, 30 Mar 2016 09:46:23 +0200 Message-Id: <1459323983-9120-1-git-send-email-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.5.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160330_004651_719917_727BC6DB X-CRM114-Status: GOOD ( 20.61 ) X-Spam-Score: -2.7 (--) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-2.7 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [2a00:1450:400c:c09:0:0:0:235 listed in] [list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, mlangsdo@redhat.com, Ard Biesheuvel , leif.lindholm@linaro.org, jeremy.linton@arm.com, msalter@redhat.com MIME-Version: 1.0 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org Hi Matt, Could we queue this as a fix for v4.6 with a cc:stable for v4.5, please? (assuming no objections from any of the cc'ees) Thanks, Ard. ----------8<-------------- Commit 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP") updated the mapping logic of both the RuntimeServices regions as well as the kernel's copy of the UEFI memory map to set the MEMBLOCK_NOMAP flag, which causes these regions to be omitted from the kernel direct mapping, and from being covered by a struct page. For the RuntimeServices regions, this is an obvious win, since the contents of these regions have significance to the firmware executable code itself, and are mapped in the EFI page tables using attributes that are described in the UEFI memory map, and which may differ from the attributes we use for mapping system RAM. It also prevents the contents from being modified inadvertently, since the EFI page tables are only live during runtime service invocations. None of these concerns apply to the allocation that covers the UEFI memory map, since it is entirely owned by the kernel. Setting the MEMBLOCK_NOMAP on the region did allow us to use ioremap_cache() to map it both on arm64 and on ARM, since the latter does not allow ioremap_cache() to be used on regions that are covered by a struct page. The ioremap_cache() on ARM restriction will be lifted in the v4.7 timeframe, but in the mean time, it has been reported that commit 4dffbfc48d65 causes a regression on 64k granule kernels. This is due to the fact that, given the 64 KB page size, the region that we end up removing from the kernel direct mapping is rounded up to 64 KB, and this 64 KB page frame may be shared with the initrd when booting via GRUB (which does not align its EFI_LOADER_DATA allocations to 64 KB like the stub does). This will crash the kernel as soon as it tries to access the initrd. Since the issue is specific to arm64, revert back to memblock_reserve()'ing the UEFI memory map when running on arm64. This is a temporary fix for v4.5 and v4.6, and will be superseded in the v4.7 timeframe when we will be able to move back to memblock_reserve() unconditionally. Fixes: 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP") Reported-by: Mark Salter Signed-off-by: Ard Biesheuvel --- drivers/firmware/efi/arm-init.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) -- 2.5.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel Acked-by: Will Deacon diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c index aa1f743152a2..8714f8c271ba 100644 --- a/drivers/firmware/efi/arm-init.c +++ b/drivers/firmware/efi/arm-init.c @@ -203,7 +203,19 @@ void __init efi_init(void) reserve_regions(); early_memunmap(memmap.map, params.mmap_size); - memblock_mark_nomap(params.mmap & PAGE_MASK, - PAGE_ALIGN(params.mmap_size + - (params.mmap & ~PAGE_MASK))); + + if (IS_ENABLED(CONFIG_ARM)) { + /* + * ARM currently does not allow ioremap_cache() to be called on + * memory regions that are covered by struct page. So remove the + * UEFI memory map from the linear mapping. + */ + memblock_mark_nomap(params.mmap & PAGE_MASK, + PAGE_ALIGN(params.mmap_size + + (params.mmap & ~PAGE_MASK))); + } else { + memblock_reserve(params.mmap & PAGE_MASK, + PAGE_ALIGN(params.mmap_size + + (params.mmap & ~PAGE_MASK))); + } }