From patchwork Wed May 25 15:11:56 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Mark Rutland X-Patchwork-Id: 68611 Delivered-To: patch@linaro.org Received: by 10.140.92.199 with SMTP id b65csp1271760qge; Wed, 25 May 2016 08:13:40 -0700 (PDT) X-Received: by 10.66.148.2 with SMTP id to2mr6631887pab.72.1464189220170; Wed, 25 May 2016 08:13:40 -0700 (PDT) Return-Path: Received: from bombadil.infradead.org (bombadil.infradead.org. [2001:1868:205::9]) by mx.google.com with ESMTPS id tv9si844170pac.109.2016.05.25.08.13.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 May 2016 08:13:40 -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; 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 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 1b5aU8-0007kL-3O; Wed, 25 May 2016 15:12:36 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1b5aU5-0007gm-R9 for linux-arm-kernel@lists.infradead.org; Wed, 25 May 2016 15:12:34 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2E3B8443; Wed, 25 May 2016 08:12:37 -0700 (PDT) Received: from leverpostej.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id E35353F218; Wed, 25 May 2016 08:12:11 -0700 (PDT) From: Mark Rutland To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] arm64/efi: remove spurious WARN_ON for !4K kernels Date: Wed, 25 May 2016 16:11:56 +0100 Message-Id: <1464189116-30898-1-git-send-email-mark.rutland@arm.com> X-Mailer: git-send-email 1.9.1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160525_081233_891863_ECAA8695 X-CRM114-Status: GOOD ( 14.58 ) X-Spam-Score: -8.3 (--------) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-8.3 points) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [217.140.101.70 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -1.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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 , linux-efi@vger.kernel.org, Ard Biesheuvel , Matt Fleming , Catalin Marinas , Will Deacon , Leif Lindholm , Jeremy Linton Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org Since commit 1fd55a9a09b0293a ("arm64/efi: Apply strict permissions to UEFI Runtime Services regions"), booting a !4K page kernel results in a boot-time splat on some systems, due to to a WARN_ONCE added in that commit which fires if the base address of an EFI memory descriptor is not aligned to the kernel page size (which might be 4K, 16K, or 64K). On page 38 of the UEFI 2.6 specification it is stated: If a 64KiB physical page contains any 4KiB page with any of the following types listed below, then all 4KiB pages in the 64KiB page must use identical ARM Memory Page Attributes (as described in Table 8): — EfiRuntimeServicesCode — EfiRuntimeServicesData — EfiReserved — EfiACPIMemoryNVS Mixed attribute mappings within a larger page are not allowed. On page 158 of the UEFI 2.6 specification, in the description of a memory descriptor, the PhysicalStart and VirtualStart fields are mandated as being 4K aligned, with NumberOfPages describing the number of 4K pages in the region. No further restriction on alignment is provided in the UEFI specification, neither generically nor in a rule specific to AArch64. So while attributes within a naturally-aligned 64K region must be consistent across memory descriptors, the regions described by those descriptors are not mandated to be 64K aligned. Not being able to apply strict permissions is sub-optimal, and worthy of some notice, but it is not helpful to erroneously suggest that firmware is buggy, nor is it beneficial to have a noisy backtrace at boot time. This patch downgrades the WARN_ONCE to a pr_warn_once, and re-words the message to also describe the implication of the insufficient alignment. Signed-off-by: Mark Rutland Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: Jeremy Linton Cc: Leif Lindholm Cc: Matt Fleming Cc: Will Deacon Cc: linux-efi@vger.kernel.org Acked-by: Catalin Marinas --- arch/arm64/kernel/efi.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c index 78f5248..95e748e 100644 --- a/arch/arm64/kernel/efi.c +++ b/arch/arm64/kernel/efi.c @@ -30,14 +30,15 @@ static __init pteval_t create_mapping_protection(efi_memory_desc_t *md) if (type == EFI_MEMORY_MAPPED_IO) return PROT_DEVICE_nGnRE; - if (WARN_ONCE(!PAGE_ALIGNED(md->phys_addr), - "UEFI Runtime regions are not aligned to 64 KB -- buggy firmware?")) + if (!PAGE_ALIGNED(md->phys_addr)) { + pr_warn_once("UEFI Runtime regions insufficiently aligned for strict permissions\n"); /* * If the region is not aligned to the page size of the OS, we * can not use strict permissions, since that would also affect * the mapping attributes of the adjacent regions. */ return pgprot_val(PAGE_KERNEL_EXEC); + } /* R-- */ if ((attr & (EFI_MEMORY_XP | EFI_MEMORY_RO)) ==